BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Google Brings App Engine's Pros and Cons to Java

by Scott Delap on Apr 08, 2009 |

Google has broadened their Google App Engine (GAE) support to include Java in addition to Python. This addition brings a large set of Java ecosystem related tools, frameworks, and languages (like JRuby and Clojure) along for the ride. However, it also imposes a number of limitations on the GAE Java applications to further Google's ability to scale and cluster them with minimal effort. The official Google blog summarizes the introduction of Java support by saying:

...We wanted to give developers something that they could be ecstatic about, but we knew we would have to marry the simplicity of Google App Engine with the power and flexibility of the Java platform. We also wanted to leverage the App Engine infrastructure -- and by extension Google's infrastructure -- as much as possible, without giving up compatibility with existing Java standards and tools.

And so that's what we did. App Engine now supports the standards that make Java tooling great. (We're working on the tooling too, with Google Plugin for Eclipse). It provides the current App Engine API's and wraps them with standards where relevant, like the Java Servlet API, JDO and JPA, javax.cache, and javax.mail. It also provides a secure sandbox that's powerful enough to run your code safely on Google's servers, while being flexible enough for you to break abstractions at will...

CNet notes that GAE is running Java 6. However, as mentioned above a number of limitations have been imposed to constrain Java to fit the GAE model. GAE Java is based on the Java 2.4 Servlet API:

  • Once a request is sent to the client no further processing can be done. This includes data streaming.
  • A request will be terminated if it has taken around 30 seconds without completing. At this point an exception is thrown. If not caught a 500 error is returned to the user.

Moving up the stack are several sandbox restrictions:

  • Applications can not write to the file system and must use the App Engine datastore instead.
  • Applications may not open sockets
  • Applications can not create their own threads or use related utilities such as timer.

java.lang.System has been restricted as follows:

  • exit(), gc(), runFinalization(), and runFinalizersOnExit() do nothing.
  • JNI access is not allowed.

In addition to these key items there are other limitations such as a JRE class loading white list. From the documentation GAE seems to impose a good deal of its magic using custom classloaders. However, they should allow other application level classloaders as long as they can operate with the above restrictions.

The next logical question is what do the above restrictions provide the user in terms of GAE application benefits. The first is scalability. App Engine uses multiple web servers to run your application, and automatically adjusts the number of servers it is using to handle requests reliably. A given request may be routed to any server, and it may not be the same server that handled a previous request from the same user. The documentation notes:

...An application can process around 30 active dynamic requests simultaneously. This means that an application whose average server-side request processing time is 75 milliseconds can serve up to (1000 ms/second / 75 ms/request) * 30 = 400 requests/second without incurring any additional latency. Applications that are heavily CPU-bound may incur some additional latency in long-running requests in order to make room for other apps sharing the same servers. Requests for static files are not affected by this limit...

Google has also provides a BigTable backed version of JPO and JPA and a Google Plugin for Eclipse facilitating easier GAE development.

Google has let a number of developers play with GAE for Java while it has been in development. Paul Hammant took it through its paces and had a number of observations

...Be aware also that multiple concurrent requests from the same client are not going necessarily hit the same servlet container at the back end. It is all apparently from the same domain name (there is no resource forwarding going on), but the there most likely will be different servlet container instances responding to the requests. This is not going to be a problem for a correctly written stateless app, but one that leverages the session for storing attributes might experience concurrency issues from two writes of to the same logical resource within that apparent map...

...Google have implement a very thorough sandbox. Its no doubt to protect them from malicious code ... XStream is one that is particularly beloved of a section of the Java community. The latest version is 1.3.1 and on initialization anywhere within the realm of GAE is throws exceptions.

Other engineers were able to get Clojure, JRuby, and Groovy working. ThoughtWorks Ola Bini has a detailed blog post on GAE's handling of dynamic languages.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

GWT + Java AppEngine has it's benefits, despite limitations by iein valdez

Indeed there are limitations, but despite those - you can create highly usable apps end-to-end in Java. I presented last night at Campfire One and was pleased to see the warm response from the crowd, including some of our own customers in the crowd.

See my Appirio tech blog post about our experience building the recruiting app we showed, including some technical points:

techblog.appirio.com/2009/04/early-peek-at-goog...

If you want to read about AppEngine vis-a-via other cloud platforms see our CIO blog post:

www.appirio.com/blog/2009/04/draft-this-campfir...

No JDBC, writing to the file system, no threads by Thomas Mueller

I'm sure people will write workarounds for most of those. The Java community always was very flexible...

Somebody will write a file system to datastore abstraction (unfortunately it's not part of the standard) - maybe Google will even help here so applications can use the standard classes (RandomAccessFile and so on). The RandomAccessFile class is not 'final'...

I am thinking about writing a JDBC driver for the datastore (really an extension to my H2 Database Engine).

Re: No JDBC, writing to the file system, no threads by Joseph Schmidt


I am thinking about writing a JDBC driver for the datastore (really an extension to my H2 Database Engine).

That would be fantastic :).

Good move but EC2 seems to have better fit for enterprise JEE by Nati Shalom

I still wonder why would i consider the use of something so restricted as GAE vs the Amazon alternative.

Our experience in building a java based platform as a service on Amazon EC2 lead me to believe that the amazon approach of working at the image level is more suitable for real-life application then the highly restricted application container approach provided by google.

In fact we were able to run real enterprise JEE application on EC2 using that model(See details here

See another user that tried GAE and decided to move to our alternative approach (See details here

Bottom line I think that google support for java is a step in the right direction however I doubt that will see enterprise applications ported into GAE anytime soon.

Nati S
gigaspaces.com/cloud

Re: Good move but EC2 seems to have better fit for enterprise JEE by Jerome Louvel

Hi Nati,

While EC2 is more flexible, GAE provides more built-in and higher level services. No JVM to install, detailled administration console provided, Java persistance framework, etc. You just get your Web application deployed and running in minutes.

BWT, I'd like to announce that Restlet (a REST framework for Java) has just been ported to GAE:
blog.noelios.com/2009/04/11/restlet-in-the-clou...

Best regards,
Jerome
www.restlet.org

Re: Good move but EC2 seems to have better fit for enterprise JEE by Nati Shalom

Jerome
First of all reslet.org looks quite interesting.
We should discuss that offline as i have some personal interest in it.

WRT to GAE i think that as it stands right now the tradeoffs and cost for using GAE in terms of performance and the ability to control the environment or add my own java services vs the value is still quite limited and limiting.
I can see how it can be a good environment for writing very simple sites that utilizes google docs or google maps but i can't real applications deployed on this environment any time soon.
On the other hand porting enterprise application on EC2 is already happening and with the right abstraction framework such as the one that we provide should be as easy as deploying on GAE.

BTW i will be speaking next week on the CloudSlam online conference specifically on that topic: Practical Guide for Developing Enterprise Application on the Cloud

You are welcome to register to this talk if your interested to learn more how simple EC2 can be even today.

Nati S.
www.gigaspaces.com/cloud

Re: Good move but EC2 seems to have better fit for enterprise JEE by Chris Richardson

Hi Nati,
While EC2 is more flexible, GAE provides more built-in and higher level services. No JVM to install, detailled administration console provided, Java persistance framework, etc. You just get your Web application deployed and running in minutes.


Jerome,

GAE is definitely interesting and useful provided that you can live within the constraints of the Java-- dialect it supports.

But if you need more flexibility including Java without significant restrictions then check out Cloud Tools and Cloud Foundry. They enable you to quickly and easily deploy your Java applications on EC2 . Cloud Foundry has a web-based console and the latest, just released version has some very cool autoscaling and recovery features.

Chris
www.chrisrichardson.net

Re: No JDBC, writing to the file system, no threads by Thomas Lukasik

If JDBC is not supported, how will you write a JDBC driver for GAE - or are you saying that your driver will be used remotely by non-GAE apps?

Re: No JDBC, writing to the file system, no threads by Thomas Mueller

> If JDBC is not supported

Actually, JDBC is supported. However you can't connect to databases such as MySQL, Oracle, and so on. But the in-memory version of H2 works. My plan is to write a 'storage engine' for H2 that uses the low-level datastore API (instead of writing to random access files).

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT