A recipe article about user friendly GWT development in IDEA using DCEVM

In IDEA version 13, unlike Eclipse, when you run a GWT project using a standard plug-in (and, as it turned out, without it, but simply launching GWT DevMode is an application to run in development mode and debug, and Specifically com.google.gwt.dev.DevMode from gwt-dev.jar - like Java Application) if you change the UI code, you need to update the browser to make the changes work. In the case of GWT, this is very critical - because when you refresh the page, it reconnects to the Code Server (the server with the project source code is needed so that you can produce debug Java code), and this takes from 10 seconds to several minutes. Here I will talk about how to change the code almost without reloading the page.


Sample code where the error occurs:

IButton b = new IButton("", new ClickHandler() { @Override public void onClick(ClickEvent event) { changedMethod(); } }); void changedMethod() { //      run time. Window.alert(" "); } 

')
Here, the method ChangeMethod () is called in ClickHandler. When changing the body of this method, changes in the browser are not applied without reloading the page. Ie, for example, if you start the application in which this button will be, then when you change the text “Changeable text” to “Changeable text 2” and click on the button, the message “Changeable text” will still appear. When you refresh the page in the browser, the changes will be applied.

The reason is that when updating hot swap classes (hot-swappable technology, without restarting the application) does not work and does not load the modified classes, no small changes would occur there.

But there is an extended “implementation” of hot swap, which allows it to work — Dynamic Code Evolution VM (hereafter referred to as DCEVM), a modification of the JRE HotSpot for being able to load modified classes. From the simple hot swap that the JRE provides (and which for some reason does not work in IDEA) has great potential - you can make changes not only in the method body, but also in its signature, as well as delete / add methods in the class and change the hierarchy classes. You cannot delete and add classes. ssw.jku.at/Research/Papers/Wuerthinger10a/Wuerthinger10a.pdf

In general, there is a DCEVM plugin for IDEA - but it includes only the JRE, but it will not work for us for two reasons:
1) To run GWT plugin in IDEA, you cannot specify the JRE under which it will be launched - it will be launched under the JDK project.
2) If you still run DevMode as a Java Application and explicitly tell it the DREVM JRE (this JRE will appear after installing the plugin), then DevMode will not start, since it will not be able to start Swing. Apparently this JRE does not work with Swing.

The original version is:
ssw.jku.at/dcevm
But it has not been supported for 3 years and does not work on Java 7 and 8, so there is a fork in which this is fixed:
github.com/dcevm/dcevm
Download from here: dcevm.imtqy.com

I took the full version of Java 7 update 51, build 3.

You need to install on the JDK, under which the development takes place - it is specified in the project settings. Put it in the JDK, because it then launches the GWT plugin, and will continue to work for all projects in the future. Installation by clicking on the button "Replaced by DCEVM".

Put on Oracle HotSpot JDK 1.7.0_67 x32 running on win 7 x64.

And then we run the GWT application as usual under debug. After changing the class, we run Run-> Reload Changed Classes and, if there are no errors during the compilation, new classes will load (this will be indicated in the Event Log window - something like "<launch configuration name>: 1 classes reloaded").

In general, DCEVM is not only suitable for GWT, but for all cases when hot swap is not working. So you can try it on other projects.

GWT 2.7 and the rejection of the plugin for the browser.

Perhaps, GWT plans to abandon support for DevMode and plugin'ov for browsers - now the GWT plugin for FireFox only works on a maximum of 26 versions, and the plugin for Chrome is terribly slow. Therefore, I am developing on FF 26.

To replace it, there is already a SuperDevMode ( www.gwtproject.org/articles/superdevmode.html ). In short, instead of executing client Java code in development mode, it allows you to compile Java code in JS and load it into the browser. Those. JS will actually be executed, as in production. The relationship between JS and Java code works using Source Maps (browser technology, with which you can match the lines of code between JS and code compiled into this JS — for GWT, this is Java code) developer.chrome.com/devtools/docs / javascript-debugging # source-maps .

But the way the development in SuperDevMode is positioned and implemented is not yet suitable for real use. There are some very serious drawbacks:
1) Now the compiled module is completely compiled, regardless of whether one class or several have changed. For small modules this is not a problem, but in the case of large modules compilation reaches 5-10 minutes. And this, of course, with disabling permutation and everything else.
2) The debug of this code is unusual - instead of the usual debug in the IDE, they suggest using debug JS in the browser itself. Example: geekbybit.blogspot.ru/2013/03/diy-working-with-gwt-codeserver-tomcat.html

GWT 2.7 talks about correcting the first minus - promising to introduce an incremental compilation. blog.oio.de/2014/03/31/upcoming-gwt-releases-2-7-3-0-2014-beyond

And the new version of the IDEA (starting with the 14th version will be enabled by default) has prepared for us a pleasant surprise - a job with SourceMaps docs.google.com/document/d/1Sf9lahq0jr0AsxR74ZE-Lntf0y5ZNk0104mhD8ozEuM/edit , youtrack.jetbrains.com/issue/ WEB-4429 # comment = 27-620687
The method is still raw, but this is only the beginning.

So in the future, it will be developed already on SuperDevMode, the benefit for convenient development with the help of it is being done a lot.

PS Thanks to Andrey Dernov from JetBrains for help in investigating the problem.