Skip to main content

Google App Engine for Java sucks

Posted by fabriziogiudici on April 16, 2009 at 2:17 AM PDT

I confess, I missed the key point while reading the announcement. But Google App Engine for Java misses a good deal of classes in the JRE: in a word, they aren't offering the full Java runtime. It shouldn't be ever called "for Java" IMO and I don't understand why Google is using the "Java" term for a thing that is not Java. While for many this is not a problem, for me it is since there is e.g. no support for java.awt.Image and such. Also, I don't see any technical reason for this choice, at least for a good deal of the missing classes.

Comments

The problems in AWT in MVM are well known to those who followed the whole MVM fiasco: http://www.google.com/search?q=MVM+AWT&ie=utf-8&oe=utf-8&aq=t&rls=org.mo... Googles alternative image manipulation service is here: http://code.google.com/appengine/docs/java/images/ The GWT Canvas which can do much of what AWT can do on the client (such as graphs etc.) without Flash is here: http://code.google.com/p/gwt-canvas/ Google might have explained every exclusion from the API in a place I am not aware of, but generally such explanations are problematic since they require debate of people familiar with the subject which is a scarce resource even in Google. Allocating people to build a more scalable AWT implementation is hard enough as it is, Sun wasn't able to do that ever. We were promised MVM for Java 1.5 and no such thing arrived Java ME has MVM pretty much since then the main blocker has always been AWT. AWT is both problematic in terms of implementation and in terms of assumptions/size. While it works for the server side implementing the whole thing just for the relatively small use cases relevant to the server side seems like a huge overkill (even for Google's resources, all resources are finite). I'm personally ecstatic that they got this out the door finally, it should have been here a year ago before python. With AWT one would assume just the QA for security/scalability effort would have dragged everything even more.

For the record, people are talking about ClassNotFoundExceptions, not HeadlessExceptions. While the difference is irrelevant for the programmer (you can't do a thing, and period) it's de-facto a fork of the JVM much similar to that of Microsoft in the past. If Google thinks that the current AWT implementation has got scalability problems, nothing prevents it from packaging their alternate imaging API (can you please give me a pointer to it? I still can't find a reference) under the BufferedImage class and relates things (ditto for other missing APIs). Don't tell me Google doesn't have time or money for this kind of approach, because it isn't true. Not to say that, in the openness and "make no evil" spirit, one would appreciate a technical explanation from Google, on why the AWT implementation would not scale etc.

I have to disagree with the whole technical reason not to support AWT. I use AWT and threads in my EE applications but I understand google perfectly here. What they are doing is legal by the Java spec (Headless Exception may be thrown by AWT code), the reasoning is AWT's implementation which is the main reason why we don't have MVM (which I assume is what google implemented on their own to lower costs). AWT doesn't work well in a shared environment since it relies on global VM wide data, earlier versions of Java EE servers also failed when AWT was invoked on unix servers since the older JDK's failed in headless mode. This was fixed in newer JDK's but at a price which Google probably isn't willing to pay (avoiding proper isolates). There are alternatives, google offers an image API but personally I'm more excited about the client side graphics abilities in JavaScript that you can leverage via the GWT API. For years I've been saying that Sun made a mistake in failing to deliver MVM for the server side leaving Java completely out of the low cost hosting market. My friends who use .net/PHP are shocked when they hear the price of my VPS hosting... I can't wait to move to GAE once CMS's add GAE support.

If Sun has a problem with Google calling something Java, then they should sue them. End of story. But don't expect much sympathy from the crowd. Sun and the JCP mafia have disappointed and outright lied to so many developers in the past, that Sun has hardly a moral leg to stand on.

Far from me the idea that Google should be blamed for a new offering on GAE. My point is that they shouldn't call Java, as I've clarified above. I can't speak for Sun, of course, but I don't feel they fear the competition with the Sun Cloud (at least, as things are now). See my comment to the other java.net blog that today deals with GAE: the point is that there are a lot of different scenarios and GAE/J fits one different than Amazon EC2 and Sun Cloud. My concerns about Sun Cloud are related to very different things, e.g. Sun's fate as an independent company, but this is another point. You have a very good point about speaking for those developers for which GAE/J fits. In your comment on the other java.net blog you made it right by posting the link to your application, because it's an example that speaks for a hundred words. Generally speaking, Sun has never been interested in offering services in this slot. They always aim at more complex scenarios - they aren't wrong in dealing with complex scenarios, but I do agree that they have missed (and are missing) a lot of opportunities. Creating a subsidiary that offered simple hosting (or buying one that did) could have been a way to monetize from Java, as well as for pushing it ever further. It's a similar scenario as with Apple's AppStore for the iPhone: Sun has got Java on mobile phones for ten years now, got money from license fees and integration support with mobile phone partners, but never started up a service business out of it. No big news: their mistake is failing to look at simpler things, in addition to blue skies.

@fabriziogiudici Fair enough. I admit that I did speed-read through the post and missed the part where you were complaining about java.awt.Image support missing. That is an omission in the support that GAE/J provides that I agree is a glaring issue (custom images, such as CAPTCHA images, won't work, etc). Forgive my hasty (and venom laced) response. I just seem to notice a lot of petty criticism of GAE/J (typically from Sun associates). I just felt that someone (might as well be yours truly) needs to represent the silent majority of Java Developers who appreciate Google instantly making Java web app hosting trivially easy and accessible to virtually everyone. Had Sun, or anyone else, come out with a similar offering, I would be singing their praises instead. Give credit where credit is due and all that -- Google should be thanked. -Bryan

@prime21: if you showed the courtesy of reading the whole post, which is unusually short for my standards, you'd find this: "While for many this is not a problem, for me it is since there is e.g. no support for java.awt.Image and such." I'm glad that it worked for you, as it will work for many. Clearly you don't need image manipulation in your application. I need it and I can't do that with GAE/J. So this is just a *blocking* issue for me, not an irrelevant one. You imagine that people blogging here has got some experience with deploying web apps and clearly the System.exit() is not a problem. Fortunately for my needs, there are other (at the moment non-Sun) Java *hosting* solutions that are much more higher quality than GAE/J and offer full Java 6 compatibility (of course, I'm restricting the comparison to the hosting features, as per your comment, but if we start to think of a cloud, such as GAE/J, things change, so the comparison itself is probably meaningless; thinking of a cloud, Amazon EC2 is definitely better than GAE/J since it offers full Java compatibilty; of course, it comes with a price). Ah, and java.net blogs are mostly owned by people - like me - who are not Sun emplyees.

As a huge Java/Sun fan who has actually used GAE/J, I have to say that I COMPLETELY disagree with this article. Developing for GAE/J was simple and straight forward. Yes, there are no threads and no System.exit() -- Boo-Freakin-Hoo. For the 99.99999999% of us who just want to host a typical java web app, this is a god-send. Hosting my EXISTING java web app on GAE/J was brain-dead simple. The author's complains are silly -- academically correct, but irrelevant in practice. Frankly, I think that Sun (and Sun employees) and just pissed the Google delivered a high-quality Java hosting solution before they did. -Bryan

Let's just say that he is, even then he is still wrong. Case in point: why do you the Java ME edition uses some kind of a poor man's version of Isolates? Look at all the trouble that Sun is going through to improve Java's deployment performance on the client. Don't you think that Java on the client, and server would have been better served with an MVM instead? But unfortunately what we got served instead is all that foot dragging, and all these lame arguments why we don't need an MVM.

But I think that Chet was referring to the MVM relevance for *desktop* applications.

I think one the big mistakes that Sun made in the Java space (other than ignoring the client side for so long), is abandoning work on the MVM/Isolates project. Java as web hosting option has paid dearly due to this terrible decision to the huge benefit of the LAMP stack. And now Java stands to lose again in the Cloud space to other alternatives due to the same reasons, be it in terms of fragmented support or otherwise. I don't care what Chet Haase thinks or might have thought at the time with regard to the MVM: http://weblogs.java.net/blog/chet/archive/2005/06/mmmmmm_vm.html History has proven him wrong and short sighted one more time, and Sun might end up paying dearly as a result, just like they did on the client. Sun and Java needs this technology very badly in order to position Java as the platform of choice for Cloud Computing.

Either we are looking at different things, or there is something I don't understand. From Google's docs at http://code.google.com/appengine/docs/java/gettingstarted/installing.html I read: "Google App Engine supports Java 5 and Java 6. When your Java application is running on App Engine, it runs using the Java 6 virtual machine (JVM) and standard libraries. Ideally, you should use Java 6 for compiling and testing your application to ensure that the local server behaves similarly to App Engine." It doesn't say "... supports the Java language": it says "... supports Java 5 and Java 6... and standard libraries". At minimum, this is poor communication. This is the first document I read about GAE/J and it's the thing driving me angry.

@opinali: well said @fabrizio: i think at this point in time when sun's fate is uncertain, any official support of java as a programming language by a big company is very welcome in my book.

@fabrizio: Yes I agree that they can't call it Java. But they are not! In the homepage I read "Java(TM) Language Support", which is correct because Java, the Language, is 100% supported. And to Google's credit, they didn't mess with the Java language even in Android where they went as far as introducing a competing bytecode format. GAE/Java eats normal WAR files, and is also compatible with several other languages that spit Java bytecode. There are some issues with specific frameworks; Google itself helped "fix" Groovy and Jython, perhaps others too. But now that this stuff went public, no sane framework provider will want to be out of the party - expect a frenzy of GAE-compatible updates of libraries over the next weeks/months... and this is a good thing because the same changes should benefit other hosting/cloud players who are less mighty than Google.

But you could level the same argument against Sun for their naming of JavaFX Script, which isn't Java nor is it a dynamic scripting language (like the unfortunately named JavaScript) as its name might imply. Googles take with GAE seems to answer a lot of problems with the hosting of Java apps - it has no safe mode unlike php. Dare say even stripped down it's pre-process overheads are still several magnitudes higher than say php though.

opinali, good points. My short answer: fine, just don't call it "Java": if you do, you're creating false expectations that aren't met. After all, as you said, Google made Android and called it Android, not Java. PS With "false expectations" I mean that you think that an idea you have in mind, and maybe you have a working prototype, can be easily deployed to GAE. Yes, maybe Google has got a cloud architecture thing that requires us to change our mind, and maybe it's right. Again: just don't call it Java.

I've had the same initial reaction, but after looking closely, Google's choices seem reasonable. They are mostly excluding stuff that has no place in the server sid (Swing), in the cloud (CORBA - which is useless across the internet and w/o enterprise integration needs), or are just not viable in a shared container (writing to the console, System.exit(), etc.). At the core of this problem is JavaSE's inadequacy for lightweight hosting: on the one hand, you can't run each app in its own JVM process because Java processes are resource hogs; on the other hand, you can't collocate multiple apps in a shared container because some bad or evil app can do many evil things that affect the others. The classloader system is better than nothing, modern microkernels like OSGi are better, but these can't provide many important types of isolation. The JSR-121 (Isolates) was supposed to fix that, but this never got out of the lab for some reason. And now we are paying the price: Google fixed the problem in a very pragmatic way, by mostly removing all the "dangerous" APIs. They also appear to have some significant extra layer of sandboxing - I won't be surprised if, for example, they run a customized JRE with features like tracking per-thread heap quotas (RTJS would provide a good staring point for that), or even a functional and safe Thread.stop() do get rid of some app locked in a infinite loop. Google has hired an incredible amount of Java talent and they can certainly maintain a custom JavaSE implementation with such enhancements. There are perhaps some missing bits that would be desirable, like AWT classes necessary for headless image manipulation, o some form of concurrency even if very managed and high-level. I hope that, in such cases, it's just a temp issue (GAE/Java is just fresh in beta) and the whitelist will grow and fix those cases. Some people have pointed to the fact that the JavaEE spec also contains a long list of don'ts, but JavaEE containers typically don't enforce such rules (e.g., I create and manage my own Threads inside some JavaEE apps when I really have a good reason for that, and I never had any container refusing to deploy or run the code). But this is a problem, containers SHOULD enforce all prohibitions in the spec. Now, Google is criticized because they rolled their own set of rules (and supported APIs/frameworks etc.) instead of adopting or developing some platform spec in the JCP. But cloud computing is very new, and the part that is not new (standard web application hosting) was ignored by Sun, the JCP, and everybody else, for well over a decade (see again the failure of JSR-121). Standard are better created following innovative technologies and not the opposite - just ask Sun, because I still don't see any JSR that covers JavaFX. Too bad that this move comes from the same Google that created Android, in my POV a very different case, Android could be much closer to standard JavaSE and JavaME APIs (but that's another debate). This will give people lots of good reasons to be wary of GAE/Java for some time. P.S.: Virtualization is not a sufficient solution. A dedicated system-level VM is even heavier than a dedicated JVM, so it's not deal for somebody like Google that wants to provide a reasonably decent and powerful service even for non-paying users.

Actually I kind of prefer that they didn't include the full standard library. IMHO the std library java.* is tied far to much to the Java language. Hopefully one day the std library will be modular enough, that there is a tiny kernel (like those classes provided by Android/AppEngine) and the rest are independent jar files you can use on any (supported) platform...

Note: Kirill was referring to the original, mistaken title of this post that I've just corrected (I couldn't keep the original as I think that the strikethrough style for the font doesn't work for a title). Thanks Kirill for pointing out the mistake. Of course, now readers can speculate it was a Freudian slip. :-)

What's a Google *Apple* Engine?