Installing, compiling and failing to use DCE VM for Eclipse Plugin development

Last night I tried to use the amazing DCE VM tool (DCE = Dynamic Code Evolution) to apply hot fixes to the APIs I was creating for the open source Eclipse API Tool Kit I'm working on (as part of the TeamMentor Eclipse Fortify Plugin).

I was trying to address the limitations of the JVM's HotSwap technology which only works on certain inline code changes, and doesn't support at all the addition and changing of new methods.

TLDR: this post doesn't have the solution for this problem (see next post which shows JRebel in action).

In this post I'm going to show the workflow/steps that I followed to:

• create a version of DCE VM that worked on OSX Mavericks (after failing to use the provided binaries, and needing to compile the DCE VM code),  
• run eclipse under the modified/patched JDK 
• get a 'hang' in Eclipse when one of the dynamic code changes was applied.

Part 1: Trying to install the binaries

The first step was to go to the DCE VM website:

Open the Binaries page, download the osx version of dcevm-0.2-mac.jar and execute it locally:

Unfortunately there were no VMs picked up by default.

So I tried to the the default OSx Java install dir,  which was here:

But that didn't work:

So I downloaded from Oracle the latest version of the OSX JDK to this dev laptop:

... which was placed here:

But that folder didn't work either

So didn't this one:

But this did:

Well, it was originally recognised as a JDK, but when I clicked on Install

I got this error:

Part 2: Building DCE VM from Source

Since the binaries option didn't work, it was time for plan B, which was to use the latest version of the code (from GitHub) and build it.

The best instructions I found came from this blog entry from Sogety: TRUE HOT SWAP IN JAVA WITH DCEVM ON OS-X :

... which took me though the following steps (you can copy and paste the instructions from that blog post)

After installing Gradle and the OSX dev tools, I cloned the https://github.com/Guidewire/DCEVM repo and switched into the full-jdk7u45 branch

Then I executed gradle

.... which took a while (with tons and tons of warning messages)

... and eventually:

... the compilation completed:

... the final step was to create a copy of the jdk1.7.0_45.jdk folder and copy the created *.dylib files into the new jdk1.7.0_45_dcevm.jdk/Contents/Home/jre/lib/server folder:

Finally I was able to try it, and I got this error (while executing java --version (as mentioned on the blog post)

... which was caused by the fact that the comment that works is java -version :)

So as you can see from the screenshot above, we now have a patched JVM with Dynamic Code Evolution enabled :)

Step 3) trying to use the patch JVM to run the TeamMentor Eclipse Plugin

Since there are a number of blog posts out there that show that once you have the patched JVM it should work (see  Dynamic Code Evolution for Java, Redeploy alternatives to JRebel and  Get True Hot Swap in Java with DCEVM and IntelliJ IDEA ), it was time to see it in action :)

I opened up the Eclipse which has the dev version of the plugin, went into the Run Configurations page, and created a duplicate of my main Eclipse Application configuration:

Then, on the Java Runtime Environment section,  I clicked on the Environments button:

Where I had to add the patched 1.7 JDK by clicking on Add...

Then choosing Standard VM on Add JRE popup window:

... selected this folder (note the jdk1.7.0_45_dcevm.jdk in the path)

... gave it a relevant name (in this case JDK 1.7 - DCE VM), and clicked clicked on Finish:

Next I selected the newly created JDK mapping from the Execution Environment drop-down:

And clicked on Run

The console window gives us a confirmation that we are running from the  jdk1.7.0_45_dcevm.jdk path (see first line in screenshot below)

And so do the Installation Details from the newly started Eclipse instance:

Next is was time to make some live changes, for example a) on a preferences page description (see top editor) or b) adding a new static field (see bottom editor):

And although it didn't work when I had it running under Run (which was expected), when I restarted eclipse under Debug , it hang as soon as I:

1) executed a script that loaded one of the classes I wanted to changed (i.e the target class was loaded into the JVM)
2) made a change in the host eclipse and saved it (which triggered the compilation of that file and the creation of a new version of the target class)
3) went back to the 'under debug' version of eclipse (which by now hanged with a OSX Spinning_pinwheel )

Which was a bummer since I was really looking forward to using the DCE VM technology.

Note that I also tried running the host Eclipse under the DCE VM, which gave me the same result (that said, on the positive side, I had both Eclipses running under the patched JDK which is quite cool)

The solution was to try JRebel which worked (see my next post)