similar to the ones shown here to help
mitigate the “abstraction penalty” you
might otherwise end up having to pay
in a well-designed object-oriented
Bringing Together Two Worlds
Of course, the creation of an environment that allows developers to build
browser-based applications in Java
addresses only one part of the development cycle. Like most developers,
we do not produce perfect code, so we
knew we would also have to address the
issues involved in debugging GWT programs.
Upon first hearing about GWT, people often assume you use it in the following way:
Write Java source. 1.
In fact, that is not the way you work
in GWT at all. You spend most of your
time in GWT’s hosted mode, which allows you to run and debug your Java
code in a normal Java debugger (for
example, Eclipse), just as you’re accustomed to doing. Only when the application is written and debugged do
you need actually to compile it into
fear of never being able to understand
proves to be unfounded.
The secret to making hosted mode
an effective debugging environment is
that it does not merely simulate the behavior of a browser while debugging in
Java. Hosted mode directly combines
true Java debugging with a real browser UI and event system. Hosted mode
is conceptually simple, and it executes
in a single JVM (Java Virtual Machine)
Launch an instance of an actual 1.
browser, embedded in-process, that
can be controlled by Java code via JNI
(Java Native Interface). We call this the
Create a CCL (compiling class 2.
loader) to load the GWT module’s en-try-point classes.
Whenever the CCL is asked to 3.
fetch a class, it checks to see if the class
methods. If not, the class can be used
directly. If native methods are found,
the class gets compiled from source
and the JSNI methods are rewritten.
Run the bytecode of the entry- 4.
point class, which will in turn request
other classes be loaded by the CCL,
which repeats the process from Step 3.
Step 3, rewriting JSNI methods, is
the really neat part here. JSNI is the
way to implement native Java methods
Thus, the hosted-mode CCL turns
JSNI methods into thunks that redirect
their calls into the hosted browser’s
the real browser DOM.
From the JVM’s point of view, everything described here is pure Java bytecode and can therefore be debugged
normally using a Java debugger. From
the developer’s point of view, he or
she can see the true behavior of a real
browser being driven by the Java source
Which brings up perhaps the most
exciting point about hosted mode: because it works dynamically with Java
code and does not depend on invoking
the GWT cross-compiler (which can be
slow), hosted mode is really fast. This
means developers get the same kind
of run/tweak/refresh behavior they
enjoy whenever working directly with
GWT thus manages to combine
the benefits of a traditional optimizing compiler with the quick development turn-around of dynamic languages. Although the compilation
technology may appear complex, it is
actually fairly standard fare for optimizing compilers. The real technical
problems we encountered along the
way revolved around our efforts to
create UI libraries to simultaneously
account for browser-specific quirks
without compromising size or speed.
In other words, we needed to supply
many different implementations of UI
functionality—version A for Firefox,
version B for Safari, and so forth—
without burdening the compiled application with the union of all the variations, thereby forcing each browser
to download at least some amount
of irrelevant code. Our solution is a
unique mechanism we dubbed
deferred binding, which arranges for the
GWT compiler to produce not one out-
put script, but an arbitrary number of
them, each optimized for a particular
set of circumstances.
Each compiled output is a combination of many different implementation
choices, such that each script has exactly (and only) the amount of code it
requires. It’s worth mentioning that in
addition to dealing with browser variations, deferred binding can specialize
compilations along other axes as well.
For example, deferred binding is used
to create per-locale specializations (for
example, why should a French user
have to download strings localized for
English, or vice versa?). In fact, deferred
binding is completely open ended, so
developers can add axes of specialization based on their needs.
This approach does create a large
number of compiled scripts, but we
reasoned it was a welcome trade-off:
you end up spending cheap server disk
space on many optimized scripts, and,
as a result, applications download and
run more quickly, making end users
In any event, our experience in developing GWT has thoroughly convinced us that there’s no need to give
in to the typical constraints of Web
development. That is, with a bit of
creativity and some dedicated effort,
we now know it is indeed possible to
retain the richness of more familiar
development environments without
compromising the experience application users are ultimately to enjoy.
Case Study: Making the Move to AJAX
Coding Smart: People vs. Tools
Debugging AJAX in Production
Bruce Johnson founded Google’s engineering office
in Atlanta, right next door to his alma mater Georgia
Tech, with the goal of producing Google Web Toolkit
and a number of related tools intended to make Web
development more efficient, effective, and a whole lot