Over a million developers have joined DZone.

Javeleon: Extending the NetBeans Platform with Dynamic Updates to Active Modules

DZone 's Guide to

Javeleon: Extending the NetBeans Platform with Dynamic Updates to Active Modules

· Java Zone ·
Free Resource

Allan Gregersen is a Post.doc at the Maersk McKinney Moller Institute at the University of Southern Denmark, doing further research on dynamic update systems.

He's responsible for Javeleon, a new small tool for increasing the developer productivity for Java developers.

Hi Allan, what's Javeleon?

Javeleon has been developed at the University of Southern Denmark in collaboration with Sun Microsystems/Oracle as a research project. The name "Javeleon" is an attempt to be creative by making a fusion of "Java" and "Chameleon" which, like a dynamic updating system, has natural adaptive skills when the environment changes.

Javeleon aligns with tools like ZeroTurnaround’s JRebel and Oracle’s WebLogic FastSwap. These tools make it possible to make changes to your Java classes while the test instance of your application is running. For example, if midway through a "wizard" in the tested application the developer notices a failure to enable the "Next >" button under the right conditions, it should be possible to fix the apparent fault in the code, perhaps rearranging some utility methods or even introducing entirely new classes, select "Reload" in the IDE, and then immediately see the wizard button begin behaving according to the new logic, without even needing to restart the wizard.

And the benefit is that development is faster? 

Yes, fast turnaround obviously eliminates wasted work time, but perhaps more importantly, it avoids breaking the programmer's concentration at a crucial moment.

How does Javeleon differ from the other two products you mentioned, JRebel and FastSwap?

Contrary to those products, Javeleon permits Java developers to make extensive changes to the class-hierarchies of the Java classes in their applications. Changing the supertype and the list of implemented interfaces is fully supported by Javeleon, thus unlimited runtime class redefinitions have finally come to Java. Not only is this a major convenience for developers, it also lowers the likelihood that some developers may be tempted to work around the limitation of changing the class inheritance hierarchy, possibly leading to a worse overall design.

Can we look at a concrete example, where we contrast the approaches taken between Javeleon, JRebel, and FastSwap?

Sure. First and foremost, Javeleon supports runtime changes to class type hierarchies. One example where this becomes interesting is where you want to factor out commonalities in a couple of classes by creating a new super class, while keeping the differences in the existent subclasses. Let's take the following code example:

// Version 1

class BluRayDisc {

private String title;

private int duration;

private List actors;



Now, let's assume that you want to add your CD collection to this application. Following standard practices, you end up (greatly simplified) with this code:

// Version 2

class BluRayDisc extends PlayableMedia {

private List actors;



class CD extends PlayableMedia {

private List artists;


class PlayableMedia {

private String title;

private int duration;


While tools like JRebel or FastSwap will fail to perform these kinds of updates, Javeleon will succeed. Existing instances of the "old" BluRayDisc class, created before the update, will behave as if they were created in version 2 after the update! Even the attribute values in the old BluRayDisc class that were factored out by the update (here ‘title’ and ‘duration’) will be automatically transferred to the corresponding attributes in the new super class for existing BluRayDisc objects.

Another very convenient and novel feature of Javeleon is the support for assigning values to newly added instance fields. In the Media application example from above, it turns out that the developer wants to link directly to the IMDB of BluRayDiscs. So in version 3 of the BluRayDisc class the following is added:

// Version 3

class BluRayDisc extends PlayableMedia {

private List actors;

// field for storing the IMDBLink

private URL IMDBLink = IMDBUtil.searchForIMDBLink(this.title);



Developers typically instantiate fields inside a constructor, but since a dynamic update system should not re-execute constructors for already created objects, this will not work. Therefore, Javeleon permits easy field assignments of new fields as long as the assignments are written outside a constructor.

In this example, Javeleon will execute the specific code for assigning the IMDBLink field, while preserving the existing field values for all the existing instance fields. That’s a very powerful feature if you ask me! However, there are some restrictions on these field assignments: 1) branching will not work, so an if-else construction will not work and 2) multiple field assignments in one line of code will not work (e.g., int a = b = c = 43). Javeleon will give a warning at load time that such assignments cannot be applied automatically.

What triggered the process of creating Javeleon in the first place?

The process began in 2006 where I found the lack of ability to dynamically update actively running Eclipse plug-ins in the Eclipse IDE annoying. I decided to hunt down a solution in the research field and apply the best candidate during my master thesis. Sadly, I found that no suitable (read "perfect") solution to this problem was apparent at that time, so I had to work a little harder to get the job done. Fortunately, early on in the process I got the core idea behind Javeleon. From there on there was no going back, and I completed a Ph.D. in April 2010, further progressing the Javeleon model.

What's the current status of Javeleon?

The current status of Javeleon is that it is ready for serious beta testing by a larger community of developers. For now, we have chosen to release a specialized version of Javeleon that adds support for dynamically updating NetBeans modules in a running application during development, which we could call a "test instance". Ease of use has been a major priority for us. Therefore, developers need only to install a NetBeans module that will enable them to add Javeleon to NetBeans Platform projects. Once they have enabled Javeleon for a project, they'll simply run the application as normal. This will enhance the traditional NetBeans module reload feature invoked via the “Reload in Target Platform" menu item. When that menu item is invoked, the module will be be transparently updated, while preserving all existing objects in the application.

Why was the NetBeans Platform chosen, why didn't you create this for Eclipse RCP?

The main reason for choosing the NetBeans Platform over Eclipse RCP is our collaboration with Oracle. Also, given that this is still a research project, we don’t have the resources to integrate Javeleon with any component platform out there. Furthermore, the NetBeans Platform seems to be the most innovative alternative on the market right now, so I think it’s a perfect fit. However, it is possible that integration with other platforms will be requested and maybe even contributed by a community in the same manner as JRebel integration plug-ins are made. Only time will tell where Javeleon is headed.

How do I get started with Javeleon?

Go to Tools | Plugins and add this URL in the Settings tab, pointing to the Javeleon update center:


You should see this:

Now you can access the Javeleon plugin and complete the wizard.

Once you have done the above, you need to enable Javeleon in your NetBeans Platform project, via "Add Javeleon to project":


Once you have selected "Add Javeleon to project", Javeleon adds a Javeleon setup line in the "project.properties" file of the application. To support multiple users using the same installation, we actually put the Javeleon configuration in the "private.properties", setting up a Java agent to the JVM arguments. Unless you want to run with Javeleon enabled in your production system, you should remove those changes. There is currently no support for removing Javeleon from an application, but users can simply remove the {$javeleon.args} in the "run.arg.extra" line of the project.properties if they want to run without Javeleon.

What does Javaleon do that is different to what "Reload in Target Platform" does?

As we wanted to be as transparent as possible with standard usage of the deployment cycle of NetBeans Platform applications, we just piggybacked on the existing "Reload in Target Platform" feature. Here is the difference between the existing implementation of this feature and what Javeleon does instead:

  • The existing "Reload in Target Platform" feature performs a complete swap of the existing module and all of its transitive dependent modules as well. Not only does this functionality wipe the entire object graph, but it also leaves potentially “stale” objects (as part of the state in non-updated modules) just waiting to throw weird class cast exceptions or linkage errors.

  • Javeleon alters this behavior by reloading the module “In Place” while preserving all existing instances. You may then wonder why we don’t just listen to file system changes, but doing so might pick up changes too quickly if the update spans multiple modules, such as when a base module is built with a binary incompatibility with client modules and the updated client modules have not yet been built. Therefore, we believe that the best way to perform module updates is by letting developers choose when to apply them.

Once Javeleon has been enabled, what should be done to verify that Javeleon is working and to try out its features?

Create a new module in the application where you enabled Javeleon. In that application, use the New Action wizard in the IDE to create a new Action in your application. In the "actionPerformed" method of the Action, write the code that you want to use as a test for the initial version. Run this application and trigger the action in the test instance.

Now, leave the application running. Turn back to the IDE and make a change to the Action class. You can make any changes to this class (or add new classes to be used by the Action method). Some small things to try:

  • The easiest way to test the support for changing the type hierarchy is to just add a new "implements" clause to this action class (e.g., "implements Runnable") and try to start up a new thread.

  • To test Javeleon's ability to change the super class, do the following: 1) add a second class to the module, 2) reload the module, 3) change the super class of the created class 4) reload the module again and you will be able to use this new type, even for existing instances in the system.

Are there any other things that Javeleon does in this context?

Well, you know, updating modern applications is much more than just updating the code. There are all sorts of resources and caches that need to be taken into account. In NetBeans Platform development you have, e.g., layer files that permit declarative registration of instance UI elements. In order to truly update the actively running modules, you need to publish the changes to those resources as well. Javeleon will transparently do this for you.

Even changes to module dependencies are picked up by Javeleon, allowing already installed modules to use classes and resources from other modules not even known of at deployment time. So that just adds to the value and usability of Javeleon, I guess. 

You worked with NetBeans Platform guru Jesse Glick on this project. Can you say something about that?

True, having Jesse as a technical sponsor has been a great experience. I don’t think you can get a better qualified man than Jesse for this project. Katherine Hartsell from Oracle external research helped with the match making and it has worked out great. Jesse has been a great partner with many valuable comments, suggestions etc.

What kind of feedback do you want from developers trying out Javeleon?

We would be very happy to get any kind of feedback from people trying out Javeleon. The system runs quite stable for the setups we have tested, but we are aware that there is a possibility that Javeleon does not yet handle some corner cases well enough to be useful. I think the JRebel guys at ZeroTurnaround will agree that dynamically redefining classes is not an easy task for a static typed object-oriented language.

Basically, we welcome all feedback. We will do our best to improve Javeleon continuously. Known issues will be described on the website so we hope that people will check at the site before sending feedback. For now, people can just send their feedback to support@javeleon.org.

Will you be at JavaOne?

Yes, If people want to speak with me or one of the other team members during the conference, I prefer to setup an arrangement by e-mail at allang@mmmi.sdu.dk, since I'll not be located at a booth space. I did a BOF at last year's JavaOne, but I'll not be giving official talks this year.

If people are interested in a small demo, we have created a small number of revisions of a Space Invaders clone built on top of the NetBeans Platform that show some remarkable new possiblities with dynamically updating the application.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}