What is GWT?
The goal of this tutorial is to help Java developers with little knowledge of web development learn how to develop web applications using GWT. Once you are done with this tutorial you should have the skills to build complex and fully functional GWT applications.
Once you are familiar with GWT after reading this tutorial, we have lots more in-depth material that will show you how to use GWT in the real world on this site. We cover topics such as module creation, deployment scenarios, using RPC sessions, history/hyperlink support and many more. We also host tutorials on lots of other technologies, like XML – SAX, DOM, Using Java to manipulate XML, database access using XML, parsing XML from web services, etc. You can find them all here. We have tutorials on Swing and graphics programming, multithreading in Java, as well as SOA related topics, and JavaME/J2ME content as well.
GWT Primer – things to know before getting started
GWT Browser Support
As of GWT version 1.4, GWT supports the following browsers:
- Firefox 1.0, 1.5, 2.0
- Internet Explorer 6, 7
- Safari 2.0
- Opera 9.0
The GWT Compiler
As of GWT version 1.4, the GWT compiler can compile source code that is compatible with J2SE 1.4.2 or older.
The GWT compiler:
- supports Java Exception handling. try, catch, finally and user defined exceptions are supported. Throwable.getStackTrace() is only supported in “Hosted Mode”.
- does not support Reflection or dynamic class loading.
- does not support object finalization during garbage collection
- does not support Strict Floating Point (strictfp keyword) and can’t ensure any particular degree of floating point precision in translated code.
- does not support Java Serialization
Runtime Library Emulation
GWT provides a JRE emulation library. This library does NOT emulate all the J2SE and J2EE classes.
The GWT JRE emulation library supports some classes from java.lang and java.util packages. Find out which classes are supported here
The GWT JRE emulation library does not support Java Serialization. In its stead however, GWT has and RPC facility that provides automatic object serialization. This RPC facility allows client-side code to make remote method calls and pass GWT serialized objects as parameters.
To find out more about the GWT compiler check out this article.
Client Side Code
Server Side Code
The piece of your application that runs on a server computer is referred to as server-side code. Your GWT application might need to interact with your server, e.g. to load or save some data. In order to do this, the application makes a client-side request (from the browser) using GWT’s RPC mechanism. While processing the RPC call, server-side code is being executed. In GWT, client-side code compilation is not dependent on server-side code. As a result, you’re server-side code does not have any of the limitations that are imposed on the client-side code and you are free to choose whatever technology you want to use in your server-side code.
When the GWT Compiler compiles your client-side code, it determines all of the different “browser idiosyncrasies” it must support, and generates a separate, highly optimized version of the application for every specific configuration. So at the end of the day the compiler will generate a different version of your application for each different supported browser. But there is more to Deferred Binding than just multi-browser detection and support. Deferred Binding is a fully generic mechanism for handling context sensitive features.
A good example of where Deferred Binding is useful is Internationalization. The GWT Compiler uses Deferred Binding to generate completely separate versions of your application for each language. So if GWT supports 4 browsers, and you write your application in 4 languages, GWT will generate a 16 different permutations of your application at compile-time. During bootstrapping, at runtime, GWT picks the appropriate version of your application to show the user.
Here is an overview of the bootstrap procedure for a GWT application:
- The browser loads and processes the HTML Host Page.
- Once the .cache.html file is loaded, the actual program logic of the GWT application is executed.
GWT Compiler Output
The GWT compiler generates a series of, sometimes oddly named, files.
As of GWT version 1.4, you should typically see the following types of files:
- <Module Name>.nocache.js (or <Module Name>-xs.nocache.js for cross-site script inclusion)
The “nocache.js” file is where Deferred Binding occurs. Before your GWT application can run, any dynamically-bound code must be resolved. This might include browser-specific versions of classes, Internationalization strings for the user’s selected language, etc. The “nocache.js” file includes a lookup table that maps Deferred Binding permutations to .cache.html filenames, e.g. “Firefox in German” and “Safari in English” would both be entries in the lookup table, pointing to different .cache.html files.
The file is named “.nocache.js” to indicate that it should never be cached, i.e. it must be re-downloaded and executed each time the browser starts your GWT application. The file must be re-downloaded each time is because the GWT Compiler regenerates it each time, but under the same file name. Allowing browsers to cache the file, would result in browsers not always downloading the latest version of the file when your application is recompiled and redeployed.
As of GWT version 1.4, types that implement the java.io.Serializable interface now also qualify for serialization over RPC, but only if they are included in the .gwt.rpc file generated by the GWT compiler. The .gwt.rpc file serves as a serialization policy and indicates which types implementing java.io.Serializable are allowed to be serialized over the wire.
HTML Host Pages
Here is a sample HTML Host Page: