Saturday, January 18, 2014

DCEVM - A JRebel free alternative

Those of you who work with web application development on a daily basis know very well that application reloading or server restarting is annoying. With Tomcat and Eclipse for example, when you make just a small change in your Java class, it still takes at least a few seconds for the change to be reflected because the whole web app will need to be reloaded. Other IDEs even require you to restart the server. This is because class hot-swapping in the JVM is severely limited. Only method body changes can be hot-replaced. All other changes (method signature, class members, etc) will require reloading the whole application.

If you work for a company that buys you a commercial hot-swap solution, like JRebel, you're lucky because usually they work out of the box and offer more functionalities. But if not, don't worry, there are free alternatives out there (DCEVM, FakeReplace, Spring-loaded...). I haven't tried them all, but it looks like DCEVM is the most advanced one and yet requires minimal configurations. 
Update June 2016: DCEVM seems to be going strong, the fork I mentioned before has been well maintained, JRE 1.8 support has been added and now there is even support for framework configuration files hot-swapping, which effectively bring DCEVM closer than ever to JRebel in terms of feature set. Check out if you haven't, there you should find everything you need to get started. IDE specific instructions can be found here: If all is well you can ignore the rest of this article, hurrahhh!
The key is how to set it up, because unfortunately, the project website hasn't been updated and the binary setup hosted there doesn't work with JDK/JRE 1.7 (if it works for you anyhow or if you can build the binary yourself, congrats you can skip the steps 1-3 below).
Update May 10 2014: Great news: there is a new DCEVM fork and the binary installers for JDK/JRE 1.7 are now available, thanks to Ivan Dubrov (more details in the comment section). So go ahead and try it. If all is fine, skip all the way to step 4 below.
After hours digging around and trying different ways of using the new VM, I managed to make it work without having to build my own installer. Needless to say, I was very excited and couldn't wait to share with my fellow developers here how I did it.

Here is the catch: don't use the installation file from the official website to patch your JRE, it's obsolete and may not work with your version of Java. The quickest way is to get the pre-patched JRE here and just use it as your server runtime, no need to mess with your current JRE. Here are the steps:
  1. Download the pre-patched DCEVM for your platform. Extract it to somewhere on your hard drive, say, C:\dcevm. Setup a runtime for this new JRE in your Eclipse by going to Windows >Preferences >Java >Installed JREs >Add >Standard VM. Click Directory and browse to your dcevm extracted location. Click Finish.
  2. Create a Server Runtime that use your new JRE: Go to  Windows>Preferences >Server >Runtime Environment >Expand Apache node and choose your Tomcat version of your choice then click Next. Browse to your Tomcat installation directory, then choose the dcevm as JRE.
  3. Create new Tomcat server instance. Choose your newly created Runtime in the Server Runtime Environment dropdown. Click Finish.
  4. Add your web project to your new server. After that, in the Servers tab, double-click your server. In the configuration page, go to Modules tab. Choose your web module, click Edit and disable auto-reloading by unchecking the checkbox > OK.
  5. You're done. Now start your server in debug mode. Make some changes to your Java class, hit refresh on your browser to see the change reflected immediately.
Thing I like the most about DCEVM is transparency. It doesn't require any plug-in to be installed into your IDE, it doesn't produce any configuration files to be complained by your source version control like JRebel does with every Java projects. With DCEVM you just patch your JRE once (the one on development environment of course), then you never worry about it again. It would be nice to have the ability to hot-swap framework configuration files as well, like with JRebel, but it's still fine otherwise, at least for me, because I find myself changing configuration files much less often than modifying view files and Java classes.

DCEVM is definitely my hotswaping tool of choice now. I can't imagine developing my Java application without it. One good news is the guy behind the project now works for Oracle and he made an enhancement proposal for it to be integrated into the JVM. See JEP-159.

While this tool is a great time saver when you work on your code, it is not recommended to be used in production (again, that's perfectly fine for me).

Happy coding guys! If you have your own approach or any tips to the reloading problem, feel free to share them here in the comment section.
Update April 12 2014: For some reason, the site I mentioned above has stopped hosting DCEVM pre-patch binaries. Too much traffic could be the reason, as seen with some Dropbox accounts hosting DCEVM binaries. I hope someone would be nice enough to work on something to replace the above. In the mean time, here is what I found:





  1. HI is it possible to use weblogic server with DCEVM?

  2. I don't use Weblogic, but it should work too. The idea is the same, you just have to find out how to configure your server to use the DCEVM as its Java Runtime. I guess it will be pretty simple in Eclipse.