Présentation de GWT par Olivier Gérardin

1. GWT = Easy AJAX
L o r ra i n e J u g
7 / 1 2/ 20 09

2. Who am I?
Olivier Gérardin
Technical Director, Sfeir Benelux (groupe Sfeir)
Java / Web architect
13+ years Java
3 years GWT
gerardin.o@sfeir.lu
blog.gerardin.info

3. Agenda
Little GWT showcase
Why GWT?
How does it work?
Key features
Myths & misconceptions
Pointers, Conclusion, Q&A

4. GWT Showcase
Ext-GWT explorer
Piano Etudes
GWTUML
Clarity Accounting
ContactOffice
MyERP, Compiere
And more: Google Wave, Timetonote CRM
…

5. Why GWT?

6. The web 0.0
Or “The Link Era”
 A web page is just a bunch of images and text with links
 Links take you to a new page
 Click on link
 HTTP request is built (from static link URL) and sent
 Wait for server to reply
 Server replies with HTML page (usually from static storage)
 Response received  blank screen
 Wait for entire page to load

7. “Dynamic” web with forms (web 1.0)
Or “The Form Era”
 In addition to images and text, a web page can contain fields and other
widgets
 A designated button submits the form
 Fill in form
 Submit
 HTTP request is built (from form parameters and field values) and sent
 Wait for server to reply
 Server replies with HTML page (usually generated on server)
 Response received  blank screen
 Wait for entire page to load

8. An example of form-based web application: Squirrel
mail

9. Server side processing
CGI
 Basic bridge to OS commands
 Very ineffective (1 request = 1 process)
Web server with dedicated module (PHP, …)
 Scripted
 Usually interpreted
Application server with thread pool management (JSP, …)
 More effective
 JSPs are compiled at first invocation
ASP, perl, whatever
…still requires full page reload

10. Java Applets
Plain Java application inside a web page!
Server interaction without page reload!
Rich UI (Swing)!
But…
 No consistent JVM support (MS vs Netscape/Sun)
 Sloooooooow start
 Hard to interface with the rest of the page
 Mostly seen as a gadget for irritating animations

11. There comes JavaScript
Client-side scripting
First usage: server-side form validation
 Avoid server round-trip when invalid
 Instant feedback
With DHTML: polymorphic client page
 Menus, animations, etc.
Cross-browser (almost)
Still no server interaction without submit/reload 

12. XHTTPR and AJAX
MS introduces Office Web Access
 JavaScript “clone” of desktop client (Outlook)
 Fetches data from server without reloading page!
How is that possible?
 New class: XmlHttpRequest
 Allows server interaction without page reload
 Response received asynchronously
 Interface updated through DOM
AJAX is born!

13. The first AJAX app: Outlook Web Access

14. JavaScript frenzy
JS becomes hype…
Cool-looking, nice to use web UIs
Everyone wants to do JavaScript
Any serious web site must have dynamic content, auto-
completion or other AJAX goodies
Widget sets / frameworks begin to emerge
 Scriptaculous, YUI, dojo, jScript, …
Anything seems possible in JavaScript
 JavaScript OS, AjaxSwing (WebCream), …

15. JavaScript hangover
Serious JavaScript hurts…
 Cross-browser compatibility nightmare
 Fix in one, break in another
 JavaScript Guru required!
 Developing/Debugging nightmare
 Weird runtime errors
 No static typing
 No refactoring
 And..
 Memory leaks
 Heavy pages
 Security issues

16. JavaScript confusion
Source: BrowserBook © Visibone

17. What to do?
Change jobs?
Subcontract?
Give up dynamic pages?
 Back to web 1.0…
Target a single browser?
 Not an option for Internet apps
Give up AJAX and use other technology?
 Plugin required
 SEO unfriendly
 Proprietary environment / learning curve
 What server-side technology to match?

18. Use GWT !
GWT gives you AJAX without the pain of JavaScript
development
 Takes care of cross-browser issues
 Allows full debugging (breakpoints, step by step, inspecting/watching
variables)
 Strong static typing  early error detection
 Full refactoring options
 No browser plugin or mandatory IDE
 Short learning curve
 Simple RPC mechanism
 But can communicate with any server technology

19. Program in Java…
GWT allows developing client-side web apps in full Java
(with only a few restrictions)
 Leverage existing Java tools and skills
 Use any IDE (Eclipse, NetBeans, IntelliJ, …)
Program like a traditional graphical client (Swing, SWT, …)
 Widgets, containers, listeners, etc.
 Use OO patterns (MVC, MVP, observer, composite, etc.)
Test like any Java app
 Use standard Java debuggers
 Test with JUnit

20. … forget JavaScript!
JavaScript is only generated:
 For deployment
 To test in actual web mode
GWT’s promise is that the generated JavaScript app
behaves exactly like the Java app
 And it does (most of the time)
(forgetting JavaScript not mandatory)

21. How does it work?

22. 4 easy pieces
1) Java-to-JavaScript compiler
2) JRE emulation library
3) Java libraries
4) Hosted Development mode

23. GWT compiler
Generates JS code from Java sources
Performs numerous optimizations
 In most cases better than hand coding
 Can generate obfuscated (ultra-compact) code
JS plays a role similar to bytecode for compiled Java
applications

24. JRE Emulation library
Provides a GWT-compatible version of Java core
classes
 Most of java.lang
 Most of java.util
 Some classes of java.io and java.sql
 For convenience only! No real I/O or JDBC!
Used when running in web mode
 Hosted mode runs in a JVM with standard JRE

25. GWT Java libraries
Utility classes
 RPC, I18N, …
Widget set
 Simple widgets (Button, TextField, …)
 Base building blocks
 In most cases map to native HTML object
 Composites = widgets built from other widgets
 Panels = widget containers
 Panels enforce a layout (vertical, horizontal, grid, …)

26. GWT widgets: Simple widgets

27. GWT widgets: Composites

28. GWT widgets: Panels

29. Hosted / Development mode
Allows running GWT apps without converting them to
JavaScript
 Code runs as Java bytecode in a standard JVM
 Embedded web browser emulates HTML rendering
 platform-dependant…
 Performs extensive checks to make sure the code is compilable to
JavaScript
Bottom line: if a GWT application performs as expected in
development mode, it will perform identically in web mode
 True 99,9% of the time

30. Key features

31. Easy development
During development, you are writing and running a
classic Java app
 Use your favorite IDE
 All IDE features available (code completion, code analysis,
refactoring, links, Javadoc, …)
 Plugins help GWT-specific tasks (launching, compiling,
creating RPC services, …)

32. Easy RPC
RPC mechanism based on Java servlets
Easy as:
1. Define service interface
int add (int x, int y);
3. Derive asynchronous interface
void add (int x, int y,
AsyncCallback<Integer> callback);
5. Implement service interface (server-side)
public int add (int x, int y) {
return x + y;
}

33. Easy JSON generation
Easy as:
JSONObject livre = new JSONObject();
livre.put("Titre", new JSONString("GWT"));
livre.put("Pages", new JSONNumber(123));
JSONArray chapitres = new JSONArray();
chapitres.set(0, new JSONString("Introduction"));

34. Easy JSON parsing
Easy as:
JSONObject livre = new JSONObject(json);
String titre = livre.get("Titre").isString().stringValue();
double pages = livre.get("Pages").isNumber().doubleValue();
JSONArray chapitres = livre.isArray();
String chap0 = chapitres.get(0).isString().stringValue();

35. Deferred binding
Appropriate code for user environment (browser, locale) is
chosen at application startup time
 ≠ dynamic binding (implementation chosen at runtime)
 ≠ static binding (implementation chosen at compile time)
Code for every combination is generated at compile time
Advantages:
 Allows app-wide optimizations
 Compensates for the lack of dynamic (runtime) loading
Disadvantages:
 Increases compilation time

36. Deferred Binding (explicit)
Deferred binding can be called explicitly:
Foo foo = GWT.create(Foo.class);
Implementation is provided by either:
 Substitution: an existing class is designated
 Generation: class is generated during compilation

37. Easy native JavaScript integration
Implement a method directly in JavaScript:
public static native void alert(String msg) /*-{
$wnd.alert(msg);
}-*/;
 Call back Java methods from JavaScript
 Pass objects back and forth
Useful to wrap legacy JavaScript libraries

38. Easy Widget reuse
Create your own widgets:
 Extend existing widget
 Works but not the most efficient
 Might expose unwanted methods from superclass
 Extend Composite
 Recommended method
 Use JSNI
 To wrap existing JavaScript widgets

39. Easy history support
AJAX app = single page
 “back” button  catastrophe…
GWT solution:
 Encode app state in URL as “fragment”
 E.g. http://myserver/myGwtApp#x=1;y=2
 Save state:
 History.newItem(token);
 React to state change (“back” button)
 History.addValueChangeHandler(…);

40. Easy i18n
Taking advantage of Deferred Binding
1. Define interface:
public interface AppConstants extends Constants {
String title();
}
3. “Implement” interface (AppConstants.properties):
title = Hello, World
5. Use:
AppConstants appConstants = GWT.create(AppConstants.class);
String title = appConstants.title();

41. Easy i18n
More advanced i18n
1. Define interface:
public interface AppMessages extends Messages {
String mailStatus(int n, String s);
}
3. “Implement” interface (AppMessages.properties):
mailStatus = You have {0} messages in folder {1}
5. Use:
AppMessages msgs = GWT.create(AppMessages.class);
String status = msgs.mailStatus(15, “Inbox”);

42. Easy debugging
In development mode, application runs as bytecode
(just like any old Java app…)
So you can debug it just like any classic Java app:
 Set breakpoints
 Step through code
 Inspect variables
 Change variables
 …

43. Easy client-server testing
Integrated application server for testing RPC
services
 Can be disabled to use external server
JUnit integration to run client-side test cases
 Hosted mode or web mode
 Full access to RPC services
 GWTTestCase, GWTTestSuite for automation
Selenium for automated GUI testing

44. Short dev cycle
Change client code:
 press “Reload”.. Done!
Change server code:
 Embedded server: press “Restart”.. Done!
 External server: hotswap /redeploy if needed

45. Easy scaling
All session data resides on client
 Similar to classic fat client
No session information on server-side
 Forget session affinity
 Add/remove servers on the fly
 Restart server without losing clients

46. “Easy” styling
Styling relies entirely on CSS
 Widgets have well-known styles
 Programmer can add custom styles
No shift from traditional HTML styling
 HTML/DOM build page “skeleton”
 Appearance tuned with CSS
Separate UI construction from styling
 With well thought styles, it’s possible to reskin completely an application without
changing one line of code
GWT styling has all the benefits of CSS with all problems of CSS
 Be careful with brower dependencies!

47. Easy Google APIs
Project gwt-google-apis
http://code.google.com/p/gwt-google-apis
 Libraries that wrap Google JavaScript APIs
 Gears,
 gadgets,
 AJAX search,
 Maps,
 Visualization,
 Language,
 AjaxLoader
 Standalone libraries (do not require JavaScript libraries)

48. [new in 2.0] in-browser development mode
Before: hosted mode uses customized browser
engine
 Heavily customized
 Only one supported browser per platform (IE on Windows, WebKit
on Mac, Mozilla on Linux)
 Platform-specific code (SWT)
 Difficult to keep up-to-date
 Browser and hosted application share the same process
 Most plugins don’t work (including Google Gears…)

49. [new in 2.0] in-browser development mode
After:
 Hosted mode shell runs outside browser
 Communicates with browser using plugin through TCP

50. [new in 2.0] in-browser development mode
Benefits
 Use any (supported) browser/version on any platform
 Behavior closer to web mode
 No interference with browser plugins
 No more platform-specific stuff in GWT (one jar for all!)
 Network protocol cross-platform possible
 Dev mode shell on machine X, slave browser on machine Y
 E.g. dev on Linux, test in IE on Windows…

51. [new in 2.0] code splitting
Before: monolithic download can become very big
 Slow startup times
After:
 Programmer can insert “split points” in code
 Hints for the compiler to place everything not required up to split point in
separate download
 Compiler divides code in several “chunks”, which are loaded on-demand
Benefits:
 Initial loading time reduced 50% on average with a single split point
 Allows on-demand module loading

52. [new in 2.0] declarative UI
Declarative construction of GUI using XML grammar
Allows automatic binding with Java code
 Assign widget references to Java fields
 Automatically attach methods as event handlers
Benefits:
 Clearly separate:
 Static UI construction (XML)
 Dynamic UI behavior (Java)

53. [new in 2.0] resource bundle
Download multiple heterogeneous resources from server in
a single request
 Images (already possible in pre-2.0)
 CSS
 Text
 Any binary resource
Benefits:
 Fewer round trips to the server
 Less overhead
 More responsive interface

54. Myths & misconceptions

55. Myth: GWT is a JS library/framework/widget set
GWT is not for JavaScript developers
Provides only Java classes

56. Myth: GWT is a framework
GWT is a toolkit (set of tools)
Frameworks may be built on top of it

57. Myth: GWT is applets
GWT app is full JavaScript
No runtime/plugin
No JRE required

58. Myth: GWT is only for Java programmers
Yes, GWT uses Java as programming language…
BUT you can also see it this way:
GWT lets you write/debug/test/refactor AJAX apps
with state-of-the-art IDEs and tools using a
statically-typed object-oriented language
GWT makes it worth learning Java!

59. Myth: GWT generates poorly performing JS
The GWT compiler generates highly optimized and
compact code
Hand written JavaScript might be marginally faster
in some cases, but it’s not worth the trouble

60. Myth: GWT only works with a Java backend
GWT includes a simple and efficient RPC
mechanism that relies on Java servlets
BUT it plays nice with any server-side technology that
can handle HTTP requests (even PHP)
 Includes XML encoding/decoding library
 Includes JSON encoding/decoding library

61. Myth: GWT has poor UI components
Yes, GWT’s builtin widgets are minimalistic…
BUT it’s not the point to provide a complete and
beautiful widget set
GWT provides the basis for rich and good-looking
components
Create your own or use 3rd party
 See Ext-GWT, SmartGWT

62. Myth: GWT apps have long startup times
Not longer than any JavaScript app
Obfuscation reduces size
Deferred binding loads just the necessary code for
the platform/language
GWT 2.0’s code splitting can split code in several
chunks
 Smaller initial download
 On-demand downloading

63. Myth: GWT doesn’t integrate with existing sites
GWT was designed from the beginning with the goal
to integrate well into existing sites
Very easy to add GWT to an existing page
 Only a few lines of HTML
 Can “hook up” to any DOM element

64. Myth: GWT has poor skinning possibilities
GWT uses CSS for styling
Can reskin a whole application without changing a
line of code (done that!)
Can split work between developer (behavior) and
designer (appearance)
Caution: CSS can introduce browser dependencies

65. Conclusion
Is GWT the future of web development?
GWT has passed reality check
Who wants to hand-write JavaScript for 6 different
browsers (and maintain it) ?
GWT = easy AJAX now !
=

66. Pointers
GWT home (downloads, docs, FAQs, guides, etc.)
 http://code.google.com/toolkit
Google groups “GWT” group
 http://groups.google.com/group/Google-Web-Toolkit
onGWT: fresh news about GWT
 http://www.ongwt.com
LinkedIn “GWT Users” group
 http://www.linkedin.com/groups?gid=129889

67. Shameless self-promotion

68. Thank you
Questions?