The Java App Engine

One of the worst kept secrets in the tech world was revealed on Wednesday night when Google announced Java support on the Google App Engine. Everyone knew this was coming, but it was still very exciting news. Last night I went to a Google Technology User Group meeting where folks from Google went into more detail on GAE/J as some folks are calling it. Here are a few of my thoughts:

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.

New developerWorks Articles: DWR and Google App Engine

This week, IBM developerWorks published two new articles that I wrote. The first article, is the third of the three part series I did on Ajax toolkits. This one is on Direct Web Remoting or DWR as it is commonly known. I had always been skeptical of DWR because of its RPC nature. However, after doing the article, I have to admit it is a pleasure to use. In the article I used the Java Persistence API (JPA) in combination with DWR. I was very pleased with being able to simply annotate some very simple, vanilla code and create an Ajax service that talked to a database. Ruby on Rails often seems magical to people in its ability to very easily work with databases and simplify Ajax development. DWR shows that you can do some pretty magical things in Java, too. DWR also makes Google Web Toolkit’s RPC code look ridiculous.

Speaking of Google (that is called a segue, if you are keeping score at home) the second article is the first of a three part series on the Google App Engine. I had mentioned some of the work on this here, and now you can read all about it on developerWorks. Of course you can also check out the application developed in the series, i.e. the aggroGator and you can get its source code here.

Google App Engine, Python, and The Gator

Today I finished the part three of a series of articles on the Google App Engine. Of course right now, GAE only supports Python. So I've been polishing my Python at the same time by reading Core Python. The end result of all this is not only the three part series, but a FriendFeed clone called the AggroGator. Oh, and I've formed some opinions as well!

First, GAE. From a developer standpoint, it is excellent. The SDK works well. It is easy to get develop, test, and deploy. I used Eclipse and PyDev, and I was very impressed with it. PyDev does a good job of providing code assist and syntax checking, something greatly appreciated by a statically typed language guy like myself.

Now once you get beyond the development phase, GAE has had some notable problems. I have been subscribed to the mailing list, and it is very active with people having problems. Personally, I had problems with urlfetch returning HTTP 503's when I could go to the same URL and get a nice little 200. This didi give me the pleasure of using GAE's logging feature to identify these errors, but there was nothing to be done about them. The 503's have since gone away, but I was just glad that this wasn't a "real" app that my job depended on.

A big part of the fun of using GAE can accredited to Python. It is a nice language. It is definitely not as elegant as Ruby or Scala. It does read nicely and has a lot of very practical sugar to it. I think it was a good choice by Google to use for GAE. I don't think they use it much for their high profile applications (I think Google Code is written in Python, but not certain.) Python is known to have better performance than Ruby, but I don't think it has nearly the popular as the other common P in LAMP (PHP.)