Skip to main content

DCEVM - A JRebel free alternative

Dynamic Code Evolution VM


DCEVM - A JRebel free alternative

Those of you who work with web application development on a daily basis know very well that reloading 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. 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 (DCEVMFakeReplaceSpring-loaded...). I haven't tried them all, but it looks like DCEVM is the most advanced one and yet requires minimal configurations.

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 toWindows >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:





Popular posts from this blog

Stretch a row if data overflows in jasper reports

It is very common that some columns of the report need to stretch to show all the content in that column. But  if you just specify the property " stretch with overflow' to that column(we called text field in jasper report world) , it will just stretch that column and won't change other columns, so the row could be ridiculous. Haven't find the solution from internet yet. So I just review the properties in iReport one by one and find two useful properties(the bold highlighted in example below) which resolve the problems.   example:
<band height="20" splitType="Stretch"> <textField isStretchWithOverflow="true" pattern="" isBlankWhenNull="true"> <reportElement stretchType="RelativeToTallestObject" mode="Opaque" x="192" y="0" width="183" height="20"/> <box leftPadding="2"> <pen lineWidth="0.25"/> …

JasperReports - Configuration Reference

Live - solving the jasper report out of memory and high cpu usage problems

I still can not find the solution. So I summary all the things and tell my boss about it. If any one knows the solution, please let me know.

Symptom: 1.The JVM became Out of memory when creating big consumption report 2.Those JRTemplateElement-instances is still there occupied even if I logged out the system
Reason:         1. There is a large number of JRTemplateElement-instances cached in the memory 2.The clearobjects() method in ReportThread class has not been triggered when logging out
Action I tried:      About the Virtualizer: 1.Replacing the JRSwapFileVirtualizer with JRFileVirtualizer 2.Not use any FileVirtualizer for cache the report in the hard disk Result: The japserreport still creating the a large number of JRTemplateElement-instances in the memory     About the work around below,      I tried: item 3(in below work around list) – result: it helps to reduce  the size of the JRTemplateElement Object                Item 4,5 – result : it helps a lot to reduce the number of  JRTemplateE…