Google App Engine for Java — First Impressions

Today’s big news is Google’s announcement for Java support on the App Engine. At Ringful, our hardware strategy is two words: cloud computing. We have multiple apps on both Amazon EC3/S3 and GAE.

EC2 is obviously more flexible since it provides a virtualized Linux environment, where you can do anything you want. GAE, on the other hand, feels much more restrictive since it is basically an app server in a scalable infrastructure. For instance, up until today, Python on Django is the only application model supported on GAE. However, as we use both services, I have grown to like GAE a lot more than EC2:

  • GAE provides automatic scaling that would just add in more resources based on the real time load of your app; EC2 requires you to actually monitor the load and bring up additional servers yourself.
  • GAE’s restrictive programming model also forces you to write apps that are horizontally scalable; With EC2, you could well write apps that cannot scale at all no matter how many server instances you start. In another word, with EC2, there could be well a false sense of scalability — until you really hit a traffic spike …
  • GAE is truly usage based — it only charges for CPU cycles that are actually used, as opposed to EC2 which charges CPU time as long as your virtual machine is up, even if it is idle. That makes GAE potentially a lot more cost effective for small apps.

So, in short, I am very excited that Java finally comes to GAE. I immediately applied for Java support in GAE accounts and wrote a couple of small apps to try it out. Overall, it feels great. I am definitely porting my Python apps to GAE Java as soon as I get around to do it. :) Here is a short summary of my first impression.

The good

* It is based on the standard JDK — not the mutilated Android Java stuff as once rumored.

* Standard servlet + JSP + JSTL stack for web apps. The same kind of setup Tomcat ships out of the box, and should be sufficient for a lot of apps.

* GWT integration if you want an advenced web framework to use with your app.

* JPA support for data persistence in Google’s BigTable.

* Standard WAR deployment. That allows developers to use any tool of their choice — ANT, Maven, Eclipse, NetBeans — as long as it can build standard WAR files.

* Most JVM languages, such as JRuby, Jython, Groovy, and Scala, are already working since the runtime is standard JDK-based.

* A lot of frameworks are already working — or can be made to work with some tweak.

* Cron and scheduler support out of the box. It is a lot better than EJB Timer.

* Direct integration with Google’s data APIs for user authentication, email sending, image manipulation and much more!

The bad

* Most of the Java EE stuff is not supported. Noticeably missing are RMI, JDNI, and JDBC. That means commonly used frameworks such as session beans and Hibernate are not supported. I have heard that JSF 1.2 does not work out of box. I do not expect Seam to work out of the box either. Bummer.

* The persistence store is not a SQL database. I understand that a non-relational data store is needed to support the kind of scalability Google needs. But, BigTable does not even provide full text search! This is Google we are talking about! The lack of SQL supports means that you probably need to re-write significant amount of code if you are porting an app to/from GAE.

* The lack of access to file system would break a lot frameworks that uses XML configuration files — think Struts! But I expect this can be fixed with tweaks in the frameworks.

* The lack of the ability to create and manage threads is probably not a big deal, since technically you should not create threads yourself in a Java EE container anyway. But still, it would be nice to create threads that processes data in the background.

* The HTTP session support in the Java runtime uses BigTable to store session data as opposed to in-memory cache. There got to be a performance for this … But I guess they have to do it this way. In a truly load balanced environment, replicating in-memory sessions is a very complicated task.

* What is the deal with JDO? They really should focus the effort on getting better JPA support. ;)

* No JMS support is a bummer.

The ugly

There is really none I can think of! Despite my numerous mis-givings, Google did a great job bringing Java into a scalable infrastructure and provide very low hosting options for the masses. I look forward to developing more apps on this platform!

5 Responses to “Google App Engine for Java — First Impressions”

  1. Wei Says:

    This is the introduction I have been looking for about GAE for Java.

  2. Joel Says:

    Nice intro. It’s a shame about JSF 1.2, that’s what I was hoping to use. Thanks for all the info.

  3. Stringbuffer.com Says:

    Thanks for a nice post.

    “The lack of access to file system would break a lot frameworks that uses XML configuration files — think Struts! But I expect this can be fixed with tweaks in the frameworks.”

    Reading from the file system is allowed as long as the content you’re reading is in your war-file. It’s only writing to the file-system that’s forbidden.

  4. NWhite Says:

    You can get full text search using Compass. The Compass developer has a blog describing how he deployed it in GAE.

  5. Frank Carver’s Punch Barrel / Google App Engine for Java — First Impressions Says:

    [...] Michael Yuan » Blog Archive » Google App Engine for Java — First Impressions [...]

Leave a Reply