Sunday, April 19, 2009

Java Cloud Edition

Last week Google announced Java support for Google App Engine. Contrary to Simon Phipp's complaint that "it's wanton and irresponsible" to only support a subset of Java, I applaud what Google has done. Here’s why.

Java is almost fifteen 15 years old, and is a huge amalgam of classes that are no longer necessary for web development. What Simon seems to be suggesting — that Google include the Swing user interface classes, AWT, and Java2D for a cloud-based offering whose only interface point is a web browser? — makes no sense.

Google is solving a huge business problem with Google App Engine's Java support. One of the biggest challenges facing enterprises is that they have a ton of data, a ton of backlogged applications that their users want that are based on that data, and no way to deliver those applications. I learned the hard way at ActiveGrid that scripting languages was not a good way to solve that problem since it required a new type of server to be installed inside the firewall. A couple of years ago I theorized that the problem could be solved with a "data wiki" type of approach that would combine a simple form editor with tiered access controls, which I still think is a viable opportunity but runs up against the challenge that enterprises do not like to buy or install software anymore, especially especially from startups.

With Google's App Engine, enterprise developers can write straightforward JSP/JDO Java applications that can connect their existing back-end databases with Google's Secure Data Connector. The apps can then be moved to run inside the firewall on a standard Java EE server. I imagine Google may even have an enterprise version of App Engine that enterprises could run inside their firewall, just like the Google Search Appliance.

Kudos to Google. Their App Engine for Java should be called “Java Cloud Edition.” They have solved a big enterprise application development problem, and have also helped to refocus Java for the cloud. Cloud services aren’t a mere trend, it’s an evolution in the software industry. Companies that aren’t cloud-based run at a huge and costly disadvantage. At iWidgets we run a Java-based cloud backend for customers, and we are not using Java classes like Swing. Anybody complaining about some of the legacy Java classes are falling by the wayside isn’t in touch with this industry transition.

I think Sun should take the class subset used in Google App Engine for Java and call it Java Cloud Edition.


Sam said...

The reality of the situation is that many web applications use Java2D to generate UI controls and other things that are then cached and served to their browser clients. Make those round buttons programmatically rather than sending them off to the designer to change the label, color or font. A few of the other things they left out were a little odd as well. JAXB, used to parse XML all the time, was another casuality that makes a lot of sense for web applications and web services.

I don't think anyone is truly bemoaning the 'legacy' java libraries like RMI and CORBA that are still in the JDK. My guess is that they will likely add in a bunch of the initial stuff they left out and it was left out because they didn't have enough time to vet it.

Peter Yared said...

Actually we use Java2D as well to crop images, so you are right that it should be in there. But Swing, AWT, RMI, etc. that are part of Java2D are useless in a cloud environment. Google didn't use the standard Python XML parser either in the Python version of Google App Engine, perhaps they think XML parsers are too processor intensive!

Jason Roy said...

Thanks for keeping us up to date.

Sara Smith said...

First of all I want to give you credits for producing such a great article about Java and Google. But I think these methods gets old now and Google changing its dynamics every now and then. So, write something new about Java.

BoostedCRM - Zoho customization grants you to spotlight on other aspects of expanding your business while growing CRM simultaneously with less effort.