Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

How to rock out with JRebel and Google Web Toolkit (GWT)

Google Web Toolkit (GWT) is a Java framework for writing web applications that lets you stop worrying about writing HTML and Javascript and how your application looks, or even works, in different web browsers. The client-side code produced by the GWT compiler is very robust and optimized for performance. Even thought GWT feels very productive, you can still use JRebel to enhance your productivity even more. In this post, we will look at some GWT features and what JRebel can do to support this cool framework.

Short intro to GWT and JRebel

When you run a GWT application it is divided into two parts: Server side and Browser side. On the server side, there is a normal JVM with Java code, but on the browser side there can be HTML/Javascript in production or Java code in development. The first one is called “production mode” and the second one is “development mode” (go figure!) and we will focus on the development mode. In development mode your entire application is in Java byte code and thus all the Java specific features are available; for example, you can debug client-side code with a Java debugger or even reload client-side code changes with 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).

For users that don’t know what JSNI methods are, here is a little bit about JSNI. One of the coolest features of GWT is the Java-to-Javascript compilation in production mode. As everything will be Javascript anyway, GWT allows you to write direct Javascript methods in your code, called JSNI methods.

But when we look at JSNI methods in development mode we will encounter a small problem, namely that we must be able to run the direct Javascript code also in development mode. To achieve that GWT has a system inside CompilingClassLoader that extracts the JSNI methods from the Java class source code and remembers it when the class is loaded for the first time. The old version of our JRebel plugin did not support those methods, so in the new plugin we built support for re-extracting the JSNI methods and making them available again when the class itself is reloaded.

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. :-)

Conclusion

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 andres.luuk@zeroturnaround.com

  • Lincoln Baxter, III

    How do we get started using this?

  • Anonymous

    As with any other framework: install the IDE plugin, generate configuration file, and enable JRebel for the Run Configuration. Should work out of the box.

  • Henry

    Coould you please provide an example project?

  • Andres Luuk

    Currently we don’t have an example project for GWT

  • If you could combine JRebel with https://vaadin.com/directory#addon/super-dev-mode-for-vaadin-6 , that would really speed things up.
     

  • arhan

    Interesting! Thanks for pointing this out.
    However, JRebel works with Vaadin our of the box. See the video:  https://vimeo.com/44089615

  • Paulo Rezende

    How can i integrate SmartGWT + Maven + JRebel? I’ve tryed to use, but no success.

  • kcsaszar

    We are trying to speed up our GWT compilation/deploy cycle to Tomcat 7. Your product looks very promising. But when I tried it with IDEA 12 and GWT 2.5.1, I noticed that Idea already seems to skip (or is just very fast) the compilation of server code when only server code changed. And when both client and server code changes, JRebel also seems to recompile the client code (which is the really time consuming part of comp/deploy cycle), just like when asking Idea to do the deploy on its own.

    In other words I have not noticed any difference when I compared the times between Idea’s deploy to Tomcat (war exploded) and JRebel’s deploy to Tomcat.
    Can you please let me know if I did something wrong, based on my description. The other thing I was thinking of is: Is it possible that things don’t work as expected because I am using a newer version of GWT? (It appears back-end-only changes deploy fast either way. Back end deployment is only very slow when front end code changes as well, because the deployment bundle for the back end also contains the client code.)

    Also, should one expect an improved turn around time when using the internal Jetty server, or only when using external ones like Tomcat?
    Given the above technology stack, do you feel that we could improve the dev cycle using JRebel?

    Thanks,
    Kornel

  • arhan

    If you check from the integrated frameworks list: http://zeroturnaround.com/software/jrebel/features/frameworks/ you will see that JRebel GWT integration is aimed at pre-2.5 versions of the framework. GWT 2.5 features super-dev-mode and therefor we haven’t investigated it any further.

    IDEA doesn’t skip the compilation. It compiles the classes in off-process mode, if enabled (and if the deployment is done via artifacts).

    Slow front-end code compilation is most likely caused by GWT.create idiom which implies calculating all the permutations during compilation. If you compile just the server side code – there’s just no overhead for that: IDEA compiles the code and JRebel will pick it up.

    I can’t answer your questions regarding Jetty vs Tomcat deployment. It is best to ask from GWT mailing lists, but most likely there’s no difference.

    JRebel still can offer you some benefits in GWT-based apps, but it depends on the nature of the application and how the client side code is written.