GWT Roundup - Johnson Discusses Open Sourcing, Blum Reveals Details of Java Compilation

Posted by Scott Delap on Dec 22, 2006

Sections

Development

Topics

Web Frameworks ,

Java

Tags

GWT

InfoQ recently caught up with GWT's Bruce Johnson to discuss the full open sourcing of the product. First Johnson was asked why now was the right time to open source the full GWT implementation:

Our open source charter (" Making GWT Better") answers this one directly. First, we've reached a pretty good multi-platform baseline now that we have OS X in the mix. Second, there are plenty of verteran GWT developers out there now, so the community can support itself much better than a few months ago. We made the easy decision that at this point, opening all the source would be far more constructive than distracting. We're really pumped to have arrived at this point in GWT's evolution.

InfoQ then asked what the biggest benefit would be in the full open sourcing of GWT:

I can't pick just one, because there are at least two "biggest" benefits :-) Now that the GWT source is hosted on Google Code, we can nearly eliminate delays getting bugfixes and enhancements into the hands of GWT users. To that end, we tried to make it very easy for GWT users to build GWT themselves. The other big benefit is that it hopefully will reassure everyone that GWT isn't going away, so they may be more willing to try an ambitious AJAX project that really takes maximum advantage of GWT.

Finally the conversation shifted to the next major items on the GWT team's radar now that OS X support, open sourcing had been addressed:

Again, I can't pick just one. There are several big ones, and we're fortunate enough to have a team that's large enough to be capable of doing a few big things at once now. The things on our mind are (1) more, prettier widgets, (2) automatic JS API generation from Java, (3) having the compiler create ".js" files to directly support mashups, (4) Java 1.5 language support, and (5) performance enhancements, both in terms of compiler optimizations and improvements in GWT's JRE emulation classes.

In other GWT news Artima's Frank Sommers interviewed Google Engineer Scott Blum this week on GWT's compilation of Java code to Javascript. Blum provides insight into the compilation process. This compilation is the core of the GWT product which was recently fully open sourced:

The basic idea is that you write your application in Java, debug it in Java, and then our compiler takes your Java program and turns it into JavaScript.

In order to allow us to do a lot of optimization, the basic strategy the compiler takes is monolithic compilation. That's our mantra. We figure out the exact and complete set of classes in your application, and where the entry point to your application is, and we use that constraint system to allow us to do a lot of really neat optimizations.

For example, suppose you have an application that is written in terms of the List interface, because you are a good object-oriented developer and use abstract types. But let's say that you only ever instantiate the ArrayList as a concrete implementation of List. Everywhere we make a call to a List method, we figure out at compile time that that's actually a call to an ArrayList method, and in cases where it's appropriate, we actually inline that call...

Blum also talks about the hardest part of compiling Java to Javascript:

The most difficult aspect is that Java's exact behavior is very highly specified. For example, when you have a class that's being initialized in its constructor, there are rules governing when the superclass constructor gets called, when you can make polymorphic method calls to your subclass, evaluation order, things like that. There are a whole series of those issues that are precisely specified.

That makes it difficult to have an accurate compiler, because there are a lot of corner cases you have to worry about. Sometimes the most natural and efficient thing you might want to do doesn't actually end up doing the right thing. Most people would never run into most of those cases, but it does make writing a compiler quite difficult. If they left things a bit looser, a little more unspecified, most people would never know or care about them, but it would make implementing a correct compiler a lot easier.

• Older >