A Look at GWT Open Source

Dietrich Kappe, Wednesday, December 20, 2006 @ 7:00 am

I've tried to get away from being just an Ajax announcement blog -- there are plently of those already -- but I thought that the release of GWT 1.3 as open source was noteworthy enough to warrant a post. There aren't really any differences between GWT 1.2 and GWT 1.3, just an open source license, but open source means more than being able to use it in your project unencumbered (more or less). At the risk of stating the obvious, you can get and read the code. Yep, read the code.

I, for one, have been dying to read the source code for GWT. One of the reasons I got into Computer Science was that I really wanted to write a C compiler. I read through the literature, including the excellent dragon book. I even built one using lex and yacc, but then along came gcc and took the wind out of my sails. It's just as well. You don't get the same programmer street cred for writing a compiler or a chess program as you once did. Still, I really dig compilers and related beasties.

I also want to know how the GWT folks can make the claim that "if it runs in the hosted mode, it will run in web mode." That seems like a bold statement to me, worthy of my best efforts to find a counterexample. I encourage you to checkout the source from SVN and studying it yourself.

So far, I've just looked at the code generation part of GWT. The business end of this is in the class com.google.gwt.dev.jjs.JavaToJavaScriptCompiler and it's various associated classes. The compiler makes use of Eclipse JDT (Java Development Tools) for parts of it's Java parsing and syntax tree construction. One place you might want to extend the implementation is in the types NamingStrategy that govern how Javascript identifiers are generated. Right now there are strategies for obfuscation (the default output) and full naming and pretty naming. It seems one should be able to do decompilation of the Javascript into Java with enough study of the compiler.

Lots of massaging of the Java is done before it is passed on to the actual Javascript generation. Just have a look at the part that optimizes:

do {
didChange = false;
// Remove unreferenced types, fields, methods, [params, locals]
didChange = Pruner.exec(jprogram, true) || didChange;
// finalize locals, params, fields, methods, classes
didChange = MethodAndClassFinalizer.exec(jprogram) || didChange;
// rewrite non-poly calls as static calls; update all call sites
didChange = MakeCallsStatic.exec(jprogram) || didChange;

// type flow tightening
// - fields, locals based on assignment
// - params based on assignment and call sites
// - method bodies based on return statements
// - polymorphic methods based on return types of all implementors
didChange = TypeTightener.exec(jprogram) || didChange;

// tighten method call bindings
didChange = MethodCallTightener.exec(jprogram) || didChange;

// remove unnecessary casts / optimize instanceof
didChange = CastOptimizer.exec(jprogram) || didChange;

// dead code removal??

// inlining
didChange = MethodInliner.exec(jprogram) || didChange;

// prove that any types that have been culled from the main tree are
// unreferenced due to type tightening?
} while (didChange);

There's quite a bit more here for some entertaining weekend code reading. For example, GenerateJavaScriptAST and company makes use of the visitor pattern for code generation from the sytax tree. I don't actually see where different Javascript is generated for different browser versions, but I'm still finding my way around the code. Even if you aren't considering contributing to the GWT system, it helps to know how the thing works, especially if one of these optimizations creates trouble for you on the Javascript side. Read code, read code, read code.

Technorati : gwt, java, javascript, open source

Related posts:

1. Tibco GI 3.2 Beta now Open Source
2. Manageability.org – Open Source AJAX Frameworks with Server-Side Java Support
3. Adobe “Open Screen” is not “Open Source”
4. Oracle and Sun: What it may mean for Open Source Landscape
5. Another Brain Fart on Why Open Source is Bad

Comments (1)

Software Development

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   From http://www.artima.com/lejava/articles/java_to_javascript.html

   “Scott Blum: It turns out that at the language level most of the browsers are pretty uniform. The actual JavaScript programming model itself is implemented fairly consistently. We don’t really have a lot in the way of specific idioms we use on particular browsers at the compilation level. In fact, the compiler doesn’t have any special knowledge of the browser that’s being targeted.”

   Have fun!

   Comment by Wilkes Joiner, Friday, December 22, 2006 @ 10:50 pm

Leave a comment