Phipps is Wrong
Sun’s Simon Phipps is wronger than wrong:
Whether you agree with Sun policing it or not, Java compatibility has served us all very well for over a decade. That includes being sure as a developer that all core classes are present on all platforms. Creating sub-sets of the core classes in the Java platform was forbidden for a really good reason, and it’s wanton and irresponsible to casually flaunt the rules.
He’s talking about Google’s JRE Class White List for Google App Engine. The white list is a subset of JRE classes that work on Google’s App Engine hosting environment.
I seriously doubt Google set out to “casually flaunt the rules”. I find it far more likely that Google sought to support as much of Java as possible within the confines of their data centers.
Progress
Java is over ten years old, yet I write this blog on WordPress, a PHP application. PHP is ubiquitous and cheap with virtually any ISP, Java is not. Java hosting is expensive and consumes a lot of server resources. For this reason, server-side Java is largely limited to in-house deployments on company servers.
Now Google offers a way to cheaply host server-side Java applications that gracefully scale to hundreds…perhaps thousands of servers. This is wonderful news!
Yes, Google only supports a subset of Java. Rather than calling this “wanton and irresponsible”, how about recognizing this as an engineering tradeoff? We programmers give up some flexibility in return for the ability to scale cheaply and easily.
Other Examples
There are other ways to scale Java to many servers. None are possible without tradeoffs. MapReduce tools like Hadoop require a completely different way of designing your applications and are not appropriate for most applications.
Terracotta tries really hard to be transparent, but you won’t have much luck running it with Java WebStart apps. That’s one of the engineering tradeoffs you live with. Much like Google App Engine’s white list, Terracotta has a list of Non-Portable Classes. Those are the breaks with distributed computing.
GWT
Much like App Engine, GWT also supports a subset of the full JRE. That’s because GWT needs to generate JavaScript to run in the browser.
Is GWT another example of Google casually flaunting the rules? Really? GWT is one of the most innovative, cutting edge products I’ve ever seen. It is a marvel of ingenuity and can only support a subset of the JRE because of its nature.
Fully supporting every JRE class and method in a sandboxed environment like GWT is impossible.
Java ME
Sun’s own Java ME supports a subset of the JRE, currently limited to JRE 1.3. See CLDC and MIDP.
Some people say Sun chose a subset of JRE 1.3 as an engineering tradeoff because mobile devices and embedded systems cannot support the full JRE.
But we all know the truth. Sun is wanton and irresponsible to casually flaunt the rules with Java ME. Shame on you, Sun.
This is only half true on the Terracotta front.
Someone got webstart to work:
http://download.terracotta.org/webstartdemo/index.html
@Steve sort of…if I understand that correctly, WebStart runs a little bootstrap program that in turn, execs a new VM with the special boot classpath required by Terracotta.
When I saw the white list I just thought “oh – google have created php-alike safe mode for Java” was that so wrong? Have to admit not allowing socket connections out scuppers most of my ideas.
Java ME can be up to 1.4.2 provided you go to CDC/Foundation 1.1. Within reason, Java ME could have kept pace with SE in terms of functionality so long as the API was carved back still. Instead, Java ME and small runtimes have been stagnated by the slow crank of the Java Community Process. It would take roughly 2 years from today if CDC/Foundation wanted to jump to 2.0. That’s not exactly Web time.