Easy Recipe GWT Recipe IDEA Using DCEVM
In IDEA 13th version, unlike Eclipse, when starting a GWT project using a standard plug-in (and, as it turned out later, without it, just launching GWT DevMode is an application for launching in development and debug mode, and specifically com.google.gwt.dev.DevMode from gwt-dev.jar - like Java Application) when changing the UI code, you need to update your browser so that the changes work. In the case of GWT, this is very critical - since when you refresh the page, you reconnect to the Code Server (a server with the source code of the project, you need to debug Java code), and this takes from 10 seconds to several minutes. Here I will talk about a way to change the code almost without reloading the page.
Example code on which the error occurs:
Here in ClickHandler, the changedMethod () method is called. When changing the body of this method, changes in the browser are not applied without reloading the page. That is, 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 press 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 you update the hot swap classes (the technology of "hot" code replacement, without restarting the application) it does not work and does not load the changed classes, no small changes would occur there.
But there is an expanded "implementation" of hot swap that allows it to work - Dynamic Code Evolution VM (hereinafter DCEVM), a modification of JRE HotSpot for the ability to load modified classes. It differs from the simple hot swap that the JRE provides (and which for some reason does not work in IDEA) - you can make changes not only in the body of the method, but also in its signature, as well as remove / add methods in the class and change the hierarchy classes. You cannot delete or add classes. ssw.jku.at/Research/Papers/Wuerthinger10a/Wuerthinger10a.pdf
In general, there is a DCEVM plugin for IDEA - but it includes only a JRE, and it will not work for us for two reasons:
1) You can’t run the GWT plugin in IDEA specify the JRE under which it will be launched - it will be launched under the project JDK.
2) If you still run DevMode, like the Java Application, and explicitly tell it the DCEVM 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 located:
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.github .io
I took the full version of Java 7 update 51, build 3.
You need to install it on the JDK, under which development takes place - it is indicated in the project settings. Put it in the JDK, because from it then the GWT plugin is launched, well, in the future it will work for all projects. Installation by clicking on the "Replaced by DCEVM" button.
I installed Oracle HotSpot JDK 1.7.0_67 x32 running on win 7 x64.
And then we launch the GWT application as usual under debug. After changing the class, run Run-> Reload Changed Classes and, if there are no errors during compilation, the new classes will be loaded (this will be indicated in the Event Log window - something like "<name of the launch configuration>: 1 classes reloaded").
In general, DCEVM is suitable not only for GWT, but for all cases when hot swap does not work. So you can try it on other projects.
Perhaps GWT plans to abandon support for DevMode and plug-ins for browsers - now the GWT plug-in for FireFox works only on maximum version 26, and the plug-in for Chrome is terribly slow. Therefore, I am developing on FF 26.
SuperDevMode ( www.gwtproject.org/articles/superdevmode.html ) already exists to replace it . In short, instead of executing client-side Java code in development mode, it allows you to compile Java code in JS and load it into a browser. Those. JS will actually be executed, as in production. The correlation between JS and Java code works using Source Maps (a technology in the browser with which you can match the lines of code between JS and the code that is compiled into this JS - for GWT it is Java code)developer.chrome.com/devtools/docs/javascript-debugging#source-maps .
But how the development in SuperDevMode mode is positioned and implemented is not yet suitable for real use. There are some very serious drawbacks:
1) Now the compilation of the changed module is complete, regardless of whether 1 class or several has been changed. For small modules, this is not a problem, but in the case of large modules, compilation takes 5-10 minutes. And this, of course, when disabling permutation and everything else.
2) 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 fixing the first minus - they promise to introduce incremental compilation. blog.oio.de/2014/03/31/upcoming-gwt-releases-2-7-3-0-2014-beyond
And the new version of IDEA (starting from the 14th version will be enabled by default) prepared for us a pleasant surprise - working 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, since a lot is done for convenient development with the help of it.
PS Thanks to Andrey Dernov from JetBrains for their help in investigating the problem.
Example code on which the error occurs:
IButton b = new IButton("Кнопка", new ClickHandler() {
@OverridepublicvoidonClick(ClickEvent event){
changedMethod();
}
});
voidchangedMethod(){
// Этот код можно изменить в run time.
Window.alert("Изменяемый текст");
}
Here in ClickHandler, the changedMethod () method is called. When changing the body of this method, changes in the browser are not applied without reloading the page. That is, 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 press 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 you update the hot swap classes (the technology of "hot" code replacement, without restarting the application) it does not work and does not load the changed classes, no small changes would occur there.
But there is an expanded "implementation" of hot swap that allows it to work - Dynamic Code Evolution VM (hereinafter DCEVM), a modification of JRE HotSpot for the ability to load modified classes. It differs from the simple hot swap that the JRE provides (and which for some reason does not work in IDEA) - you can make changes not only in the body of the method, but also in its signature, as well as remove / add methods in the class and change the hierarchy classes. You cannot delete or add classes. ssw.jku.at/Research/Papers/Wuerthinger10a/Wuerthinger10a.pdf
In general, there is a DCEVM plugin for IDEA - but it includes only a JRE, and it will not work for us for two reasons:
1) You can’t run the GWT plugin in IDEA specify the JRE under which it will be launched - it will be launched under the project JDK.
2) If you still run DevMode, like the Java Application, and explicitly tell it the DCEVM 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 located:
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.github .io
I took the full version of Java 7 update 51, build 3.
You need to install it on the JDK, under which development takes place - it is indicated in the project settings. Put it in the JDK, because from it then the GWT plugin is launched, well, in the future it will work for all projects. Installation by clicking on the "Replaced by DCEVM" button.
I installed Oracle HotSpot JDK 1.7.0_67 x32 running on win 7 x64.
And then we launch the GWT application as usual under debug. After changing the class, run Run-> Reload Changed Classes and, if there are no errors during compilation, the new classes will be loaded (this will be indicated in the Event Log window - something like "<name of the launch configuration>: 1 classes reloaded").
In general, DCEVM is suitable not only for GWT, but for all cases when hot swap does not work. So you can try it on other projects.
GWT 2.7 and abandonment of the plugin for the browser.
Perhaps GWT plans to abandon support for DevMode and plug-ins for browsers - now the GWT plug-in for FireFox works only on maximum version 26, and the plug-in for Chrome is terribly slow. Therefore, I am developing on FF 26.
SuperDevMode ( www.gwtproject.org/articles/superdevmode.html ) already exists to replace it . In short, instead of executing client-side Java code in development mode, it allows you to compile Java code in JS and load it into a browser. Those. JS will actually be executed, as in production. The correlation between JS and Java code works using Source Maps (a technology in the browser with which you can match the lines of code between JS and the code that is compiled into this JS - for GWT it is Java code)developer.chrome.com/devtools/docs/javascript-debugging#source-maps .
But how the development in SuperDevMode mode is positioned and implemented is not yet suitable for real use. There are some very serious drawbacks:
1) Now the compilation of the changed module is complete, regardless of whether 1 class or several has been changed. For small modules, this is not a problem, but in the case of large modules, compilation takes 5-10 minutes. And this, of course, when disabling permutation and everything else.
2) 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 fixing the first minus - they promise to introduce incremental compilation. blog.oio.de/2014/03/31/upcoming-gwt-releases-2-7-3-0-2014-beyond
And the new version of IDEA (starting from the 14th version will be enabled by default) prepared for us a pleasant surprise - working 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, since a lot is done for convenient development with the help of it.
PS Thanks to Andrey Dernov from JetBrains for their help in investigating the problem.