I'm the primary inventor of the Javeleon class reloading technology. Currently, I'm holding a post.doc. position at the University of Southern Denmark where I continue my research on dynamic software updating. I've spoken at JavaOne in 2009 and again in 2011. Allan has posted 12 posts at DZone. You can read more from them at their website. View Full User Profile

Who Said Runtime Class Reloading Is Hard in Java?

09.27.2011
| 19017 views |
  • submit to reddit

Are you sometimes frustrated spending precious development time restarting your Java application all the time? If so, read on!

If you haven’t already stumbled across Javeleon, I would like to introduce it to you and give you a sneak peak of some of the big changes now supported in the new version 1.5. You can hear more about Javeleon at this year’s JavaOne, in a session entitled “Who Said Runtime Class Reloading Is Hard in Java?”.

Javeleon is a small tool that boosts productivity by allowing you to see code changes in a running application while preserving all of the application's state. So, basically, developers can use Javeleon to speed up development by skipping the restart phase completely. Not only will this save you time immediately, it will also help you to keep focus on development task at all times.

Changing the Java Component Inheritance Hierarchy

While there are tools out there already that do most of what Javeleon does, especially JRebel, Javeleon has some nice additional features that may be of interest to you. Most importantly, Javeleon supports changes to the inheritance hierarchy; that is you are free to change the set of implemented interfaces as well as the super class as defined by the "extends" clause. While not all changes require us to change inheritance, this feature really comes in handy if you, e.g., want to abstract reusable stuff away to a new super class. Also, changing the set of implemented interfaces is in fact a quite common change as well. Just look at the example below taken from a NetBeans Platform application below.

public final class EditorTopcomponent extends TopComponent 
/* Add this by a dynamic update:*/
implements LookupListener */ { public EditorTopcomponent () { name = "something else"; initComponents(); setName(NbBundle.getMessage(testTopComponent.class, "CTL_testTopComponent")); setToolTipText(NbBundle.getMessage(testTopComponent.class, "HINT_testTopComponent")) } }

Typically, when we want different components to interact with each other in a loosely-coupled way we use the Lookup pattern in the NetBeans Platform. We simply need to implement the LookupListener interface, right? Indeed, this change is possible with Javeleon at runtime. Indeed, Javeleon can change the inheritance hierarchy at runtime, but there is more to it than that. Javeleon actually turns all of the objects that were already created before the update into correctly behaving objects reflecting the new type of the declaring class, even when used in reflective invocations.

Support for Standard Java SE Applications

Previous releases of Javeleon came with out-of-the-box support for NetBeans Platform applications only. But, in the new 1.5 release, we’ve added beta support for standalone Java applications as well.

And best of all, it is almost too simple to setup. Just add a few arguments to your JVM configuration and you are ready to apply dynamic code updates.

While the Javeleon NetBeans plug-in has built-in support for adding these arguments by a mouse click in your project, it takes only seconds to setup in, e.g., Eclipse as shown in the screenshot (click to enlarge it).

In your lanch configuration for your project add the Javeleon VM argument.

Then save the configuration and enjoy automatic class redefinitions when you modify your Java files. Remember to have ’Compile on save’ switched on.

Published at DZone with permission of its author, Allan Gregersen.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Michael Remijan replied on Tue, 2011/09/27 - 11:34am

Interesting article on a great piece of technology but writing "Just add a few arguments to your JVM configuration and you are ready to apply dynamic code updates" is not very helpful.   How about a hello world tutorial to show & explain how it works.

Allan Gregersen replied on Tue, 2011/09/27 - 12:23pm in response to: Michael Remijan

Thanks for your comment. I guess what you're looking for is easily found from our web-site linked to in the article. I could have provided the hello world example, but didn't since I felt that was covered elsewhere. Also, the setup differs if you use NetBeans, Eclipse, IntelliJ or other IDE. In NetBeans we have plug-in support for adding Javeleon to your project by a single mouse-click. In other IDEs you'll have to add the arguments to JVM args yourself. What I'm trying to say is that I didn't wan't the article to go into differencing setup instructions, thats the job of our installation pages on the web page.

Doug Graham replied on Tue, 2011/09/27 - 12:52pm in response to: Michael Remijan

There's more information of the type you want here:

http://netbeans.dzone.com/nb-javeleon-automatic-update

Serguei Mourachov replied on Tue, 2011/09/27 - 3:00pm

Allan, does Javeleon has any limitations?

Can it be used for production code deployment, especially for big scale apps running on multiple servers ?

 

Anton Arhipov replied on Tue, 2011/09/27 - 3:51pm in response to: Michael Remijan

-javaagent:/path/to/javeleon.jar at the screenshot should be quite easy to add :)

Allan Gregersen replied on Tue, 2011/09/27 - 4:02pm in response to: Serguei Mourachov

Let me put it this way. I wouldn't recommend using any dynamic updating system right now for a large-scale multiple server setup in production no matter how performant and stable it may be. Simply because there are some runtime phenomena that you can run into when trying to automatically adapt an apple into a pear ;)

If you're interested you can read more about those phenomena - the causes and effects they have on a system in a research paper. You can find a link to the paper under Publications on our web site.

I'm not saying that Javeleon can't be used for large-scale projects (we would be very happy to hear about experiences of this kind), just that the developers need be aware of the risks and how to deal with them. We are currently researching better ways to do e.g. runtime refactoring and more expressive hooks for adapting the state, but walking this path we loose the language transparency that is so important IMHO. So these new capabilities must be optional stuff that developers can use to tweak the result of a dynamic update. Javeleon will certainly evolve in the future to allow capturing more of the intentions of developers.

Keith Barret replied on Wed, 2011/09/28 - 5:45am

Sounds interesting. Never heard before. But Javeleons licence text reads as follows :

SDU grants you a [..] limited license without fees to use internally
the Software for non-commercial purposes.

The website nevertheless does not mention any conditions for commercial use. So is this another product plug article on dzone? I really got a bit tired of those esp. by one from another DZone writer praising some revolutionary debugger products here.

Nevertheless nice pointer to this JRebel alternative!

Allan Gregersen replied on Wed, 2011/09/28 - 7:39am in response to: Keith Barret

oops. That's a mistake. Thanks for reporting it. It was due to an old license file that we did not update before the 1.5 release. The license text will be changed ASAP into:

SDU grants you a [..] limited license without fees to use internally the Software for non-commercial purposes and commercial purposes.

We will also provide more information about licensing and how the registration works at our wep-site very soon. In essence, the reason for us to register users is to see how many are using Javeleon actively to attract funding for further development of the tool. Hope for understanding that we don't have everything sorted out already. Afterall, we are only researchers.

Edit: We have now updated the license file on the web page, and added a section on the license page explaining the license model. Hope this resolves any questions about licensing you may have.

Vadim Gerassimov replied on Wed, 2011/09/28 - 7:59am

Do you have any public plugin API for writing extensions that are framework specific features aware (like in jRebel)?

Allan Gregersen replied on Wed, 2011/09/28 - 8:24am in response to: Vadim Gerassimov

Not yet, but we will definitely need such API eventually. We plan to extend the support for different frameworks from now on in upcoming versions. We are always open to suggestions and collaborations for specific extensions.

However, we do have a few general hooks for making framework specific extensions. You can write a public void javeleon$$updated() method that will be invoked per object just before the object is used after the declaring class have been updated. We also have an undocumented mechanism to take user-specific actions to reload events, that works by setting the system property -Djaveleon.reload.listener=org.myorg.MyClass. Then org.myorg.MyClass should implement ChangeListener, and on every reload event the actionPerformed method is invoked. I know this is limited, but can be used to do some framework specific things like refreshing caches.

Rob Kenworthy replied on Wed, 2013/02/13 - 8:09pm

Anyone interested in java class reloading should check out Feenix. It requires no application integration, you can drop the feenix ear into your favourite app server for extremely easy setup, and its entirely free. Rob

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.