Short intro to GWT and JRebel
JRebel for GWT is available in development mode, and if you have installed JRebel then the support for GWT is enabled by default. We don’t support production mode because compiling JS from Java is terribly slow, especially if deferred binding is in use via GWT.create.
GWT-s server side with JRebel
In the server side of a GWT application, you run a normal Java server. This means that when you make a change to the Java code in there, then you must redeploy your application in order to see it, which can take 30 seconds to 10 minutes depending on your app size and tech. On the server side of GWT, there is no easy way to update code quickly like you can achieve by refreshing on the browser side. This is where JRebel comes in to truly save time, money and developer lives ;-) In server side the benefits from JRebel functionality is clear: you eliminate the redeploys in there just by using JRebel.
GWT-s browser side with JRebel
GWT-s browser side looks much more interesting than the server side. Each time you open a new browser window (or refresh an old one) a new GWT session is made for you by the GWT browser plugin. In Java code, this means there will be new ClassLoader and resource cache just for your session. So because every new session gets its own ClassLoader and resource cache, you can see changes to your Java code just by refreshing the browser. It’s fun and comfortable.
Of course GWT is pretty smart, so everything must not be regenerated on every new session. So why would we need JRebel on the browser side of GWT?
The benefits of JRebel on the browser side are not that as evident as they are on the server side but they are there – with JRebel you still maintain current application state if you reload your client side code, and you don’t have to refresh your browser.
What about JSNI methods?
Our customers and users will be happy to hear that we’ve recently updated our JRebel-GWT plugin, which has now implemented the reloading of the JSNI parts of the changed class as well (it didn’t before).
GWT class generation
Another big part of GWT is class generation. GWT has a lot of browser-side resource files from which it generates different Java classes. There are for example i18n files and ui.xml files that generate different Java code. In a running application this is probably a big performance win, but for a development time class update this is a nightmare. Luckily, JRebel can update even those files in run-time with a simple browser refresh, so there you go.
Let’s take a look at GWTs support for i18n. In GWT, when you make your message classes and put some text references in them and make some properties files with the text in them, then on the first request those files with contents from properties files are compiled into new Java classes.
The problem with this generation is that first all the properties files are basically made into a big list, and then i18n-ed files will take their labels from any one of the files. Now, when any one of the source properties files is changed then JRebel must regenerate all of the i18n-ed files because GWT does so in the initialization and there’s no way to find out which generated file the new text is meant to go.
One solution would be for JRebel to generate different i18n files in development mode, so that the i18n content comes from a map instead of directly compiled file. So we could just update the changed text to a map and then the files would automatically get the new content.
Another possibility for JRebel would be to do a more intelligent tracking for properties sources to Java sources but this would take to much more time and memory.
So we decided just to regenerate everything because this has the smallest possibility to break something. :-)
GWT is a very innovative tool for writing web applications, but any developer who uses GWT can certainly benefit from JRebel, both on the server side (instant class reloading in the running app), and also on the browser side (no need to refresh because JRebel can reload the classes and even regenerate GWT-s generated classes).
The goal of using JRebel with GWT is to eliminate server restart/browser refresh when you change some parts of the code. That includes Java code (of course) and also JSNI functions, all sorts of generated classes (i18n, templates etc). If there are any classes that JRebel does not regenerate yet, please let us know – we’d be happy to improve GWT support in JRebel!
If you have any comments, please leave them below or let me know at email@example.com