GWT—An Important Java Technology: Features, Future and Wishes
Join the DZone community and get the full member experience.Join For Free
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.
- A single code base for client and server.
- 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.
- gwt-dnd: Implements Drag and Drop in pure GWT.
- GWT Mosaic: Also extends GWT, but as pure GWT and with less widgets/features.
- 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.
- 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.
Opinions expressed by DZone contributors are their own.