Over a million developers have joined DZone.

GWT—An Important Java Technology: Features, Future and Wishes

DZone's Guide to

GWT—An Important Java Technology: Features, Future and Wishes

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

The Google Web Toolkit (GWT) has become one of the most important Java technologies, as it gives it a credible web platform strategy. I used to be doubtful of the extra compilation step and developed with DWR and Dojo, but have since become a convert.

Cool features:

  • A single code base for client and server.
  • Great development tools, via Eclipse: refactoring, code navigation, etc. This was one of the reasons the creators of GWT chose Java as the source language. Server-side JavaScript certainly would have been a possibility, and compiling JavaScript to JavaScript is not unheard of, either.
  • Very quick turn-around: after making changes, the server and client can be reloaded quickly to reflect the changes (only the first start of the client is a bit slow, subsequent reloads are fast).
  • Development tools easy to install: All you need is two Eclipse plugins and you are done.
  • IDE support: The Eclipse plugin helps with various coding tasks and errors (such as keeping Service and AsyncService consistent)
  • Web application easy to install: GWT produces a WAR file. Drop it into a servlet container such as Jetty or Tomcat. Done.
  • Fast and reliable GUI layout: Still limited compared to what Swing and SWT offer, but for the first time acceptable.
Extending the basic features: For someone who has already programmed Swing or SWT, it is very easy to get started with GWT. After a while, you will probably be looking for advanced features. Luckily, a lively community has grown around GWT to fulfill this kind of need.
  • gwt-dnd: Implements Drag and Drop in pure GWT.
  • Smart GWT: GWT does currently not have too many widgets. Smart GWT is a GWT wrapper around the SmartClient JavaScript client. While GWT is really good at this kind of wrapping, there is some baggage involved: load times of web applications increase, and there is a new API to learn.
  • GWT Mosaic: Also extends GWT, but as pure GWT and with less widgets/features.
  • Other wrappers for JavaScript libraries exist. But beware, some of them have very restrictive licenses.
What the future will bring:
  • Currently, the GWT incubator hosts experimental features. Long-term, its parts will be migrated to either separate projects or the GWT core.
  • A post reveals interesting things about GWT’s future. For example, it will get data-backed widgets.
What I am missing:
  • More widgets: The current widgets are limited (menus don’t ensure that they are visible, no support for shortcuts, no resizable dialogs, no context menus, etc.) and there are not enough of them. I expect this area to improve quickly, though, now that all the important foundations have been laid (event handlers, modular CSS, layout panels).
  • Switching back-ends: Many computers are only intermittently online. Programming an offline mode for a GWT application is difficult, because the server usually hosts important functionality. A hypothetical way of solving this is by installing a back-end locally. The client could switch between this back-end and the server. Managing installed back-ends should work similar to Java Web Start. A local back-end could also provide a GWT application with desktop features, because it has access to desktop resources such as the file system.
  • Better client-side modularity: I love Eclipse’s modularity, especially when working in a team. You can have a core plugin that is extended via other plugins residing in separate projects. It would be nice if one could extend a GWT application in a similar fashion. On the server side that is possible via OSGi. On the client side, that is currently not possible.
  • Sending binary data from server to browser: For example, one cannot create images on the server and send them to the client via RPC. Data URIs are a work-around, but a poor one.
  • Annotations for hiding code from the client: If an object is transferred back and forth between client and server, there are often some server-only methods. An annotation would allow one to hide those methods. There is an issue for this feature. You can star it, if you would like to see it fixed.
  • Instantiating classes via class literals: There is no Class.newInstance() in client-side GWT. One has to resort to sending a factory to the client.
  • Two two useful methods: Class#getSimpleName(), String.format() are simple to implement, so I don’t see the reason for not doing so in client-side GWT.


From http://2ality.blogspot.com/2010/04/gwt-important-java-technology-features.html

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}