1.) First of all, kudos to Google for supporting a lot of the standards in Java. They did the same thing with Python on GAE, but there are a lot more standards to deal with in Java and those standards tend to be harder to implement.
2.) Also major props to Google for working so well with partners. They had big partners like IBM, but also smaller ones like ThoughtWorks. The ecosphere around GAE/J is off to a great start. Of course reaching out to partners is probably a big reason for the lack of secrecy about GAE/J, but it is certainly worth it.
3.) The Eclipse tooling is outstanding. I know some folks were a little dismayed that they would have to use Eclipse instead of IntelliJ or NetBeans, but what can you do? Eclipse is king, and the developer experience with the Google tools is second to none.
4.) Speaking of standards, support for JPA is great. So you can't do joins or aggregates, but did you really think you could or should be able to do that on GAE? After all, you have a non-relational store (BigTable) behind all of this.
5.) On the other hand, support for JDO is ... surprising and a little puzzling to say the least. Heck, I thought Gavin King put a wooden stake through the heart of that would-be standard a long time ago. At least you can eschew it in favor of a standard that people actually use (JPA.)
6.) No threading is not entirely suprising, but it lights the way to a bigger issue. The GAE road map has talked about task queues/background processing for awhile now. Google announced cron jobs this week as well, but those are limited to 30 seconds of execution time, only 10/day, and are schedule at a specific time. Here is another Java standard for you: JMS. I think GAE/J needs this, as well as some kind of thread pool (or substitute) for processing. BigTable (as a backing store for a queue) and cron tasks are not enough. Heck, even one of the App Engine success story/presenters talked about how they simulated (quite cleverly I might add) batch processing.
No comments:
Post a Comment