Sun turns Javascript into Java. Google turns Java into Javascript.

Yesterday, in my treatise about why Sun's emphasis on R&D and developer communities is too easily dismissed, I slipped in a bit of news about a skunkworks project at Sun called Phobos that the company unveiled this week at JavaOne.  In the bigger scheme of things, Phobos is about how developers that work in languages other than Java will be able to program a Java Runtime Environment (JRE) with those non-Java languages.  This pick your favorite language for scripting runtimes is called "dynamic language support" and it has long been a feature of Microsoft's .Net runtime environment. 

This has been a subject that's near and dear to Sun director of Web technologies Tim Bray's heart as evidenced by the Dynamic Java summit on the subject that he held on Sun's Menlo Park campus some 18 months ago.  In the time since that summit, languages other than the ones that were represented there (Perl, Python, Parrot, and Groovy) have been taking off or experiencing a ressurection of sorts.  Namely the uptake in Ruby, PHP, and Javascript (under the auspices of a technique known as AJAX) are generating considerably more interest on Sun's behalf in dyamic language support the Java platform.

So, in the big picture, Phobos, which is about scripting server side Java with Javascript is very much about the company's willingness to move to more of a dynamic language model.  In the small picture, it's about Javascript developers who prefer to work with one language when developing applications that require scripting on both the client-side (where Javascript is already the preferred scripting tool) and the server side where Javascript, as a programming platform has been dead for years.  So, is Phobos really Server-side Javascript: The Sequel?  With server-side code typically not involving a browser where AJAX really sings, will someone with a twisted mind figure out a reason to do server-side AJAX and run a JRE with it?

But wait, there's more.  Just when you thought that Java and Javascript had nothing to do with each other, and then, suddenly, thanks to Sun, now they do, Google comes along and does almost the same thing, but in reverse.  Although I missed the announcement at JavaOne, I had a chance to interview Google Developer Programs product manager Brett Taylor today to get the details.  Said Taylor in the phone interview:

On Wednesday, we launched the Google Web ToolKit (GWT).  It's a Java software framework for developing AJAX applications.  With it, you can write your applications in Java, and use the Google Web Toolkit Compiler to convert that code into browser-compliant Javascript and HTML. With the Web Took Kit, Java developers can use the development tools that they're used to using and they can write an entire application without ever using Javascript?

So, whereas Sun's Phobos allows developers to run the Java platform with Javascript, Google's Web TookKit allows developers to run the Javascript platform with Java.  What were Google's motivations?  Not too different from Sun's.  In supporting Javascript on the server side, Sun saw the convenience of giving developers programmable access to both ends of the pipe with one language. Plus, giving Javascript and AJAX programmers access to the Java Runtime Environment is a way of exposing the functionality of the JRE to a new class of programmers.

According to Google's Taylor, Google picked Java because a lot of Java developers are focused on Web development (Google's obvious sweet spot) and don't spend much time with Javascript.  By giving Java developers access to the Javascript environment without having to code Javascript, Google can more easily expose the functionality of its APIs to an entire class of developers that might not otherwise think about using them.  Said Taylor during the interview:

The way Java supports static type checking and modularity is really important for larger projects and that's where AJAX development suffered. It hurt the development cycle to not have a more strongly typed language. So, this is targeted towards ascale of application where it's particulary difficult to use Javascript.

Taylor said the Google Web ToolKit is also IDE agnostic.  The advantage, according to Taylor, is that Java developers can use their favorite tools to develop and debug the application.  In other words, they can do everything they'd normally do as if the app were being developed in Java and when they're pretty sure they've got it working, then they can compile it to Javascript.  To facilitate debugging, the Google Web ToolKit ships involves two modes: the Web debuingging mode and a production mode (or deployment mode). In the  debugging mode, Taylor says, you can run the AJAX application right in the Java Virtual Machine:

Normally with AJAX, when you click a button or link, a Javascript handler is invoked to handle that event. For the debugging mode, we ship with a browser so that when you click on that button or link, it invokes the Java event handler instead.  So, when you're debugging, you can uuse all of your tools like Eclipse to debug it, and then, when your ready to  deploy, you switch to the production mode.

One note however for the many Java developers building behind the firewall applications: According to Taylor, the Google Web ToolKit does not lift the licensing barrier that currently prevents Google's APIs from being incorporating into applications that aren't exposed to the public Web.  To officially get programmatic access to some of Google's functionality for behind the firewall applications, Taylor said businesses must look into acquiring one of Google's search appliances. 

In terms of some of the neat things that Google Web Tool Kit does under hood, one of them is that it automatically resolves browser dependencies which is good.  Java programmers are used to writing their code to certifiably Java-compliant runtimes which means they don't have to worry about code that will run in one place and not the other.  Thrusting them into an environment of target uncertainty is not something most Java programmers would appreciate from a productivity point of view.  Google Web Took Kit ameliorates the headaches of having to maintain separate chunks of code for each browser and the subsequent branching logic the developers typically must install to get their code working smoothly across all Web browers (perhaps a good reason for AJAX developers to become Java developers!).

Another neat trick of the Took Kit's is how it optimizes the code to keep the overhead and execution time down.  To the extent that it handles translation from one language to another, the Tool Kit is pretty much middleware and middleware, as Java developers well know, typically involves a performance hit in order to consistently get the translations right.  So, the potential for a large piece of Java code to generate and even larger chunk of Javascript is pretty good. To optimize the code, the Took Kit first analyzes the Java code, then it eliminates any Java classes or methods that weren't explicitly used in the code, and then it compiles it into Javascript.  But, when consider how some hardcore Java applications can end up being rather sizeable, Taylor admitted that "there is obviously a limit and that's going to be a practical issue for very large applications."