Javeleon
From APIDesign
Javeleon is 100% pure Java implementation of Hotswap. On a base level I envision it as complementary to DCEVM by Thomas Würthinger, just not implemented directly inside HotSpot, but externally via java.lang.instrument package. However Javeleon value (from my point of view) is in providing additional hooks for integration with the NetBeans platform. For example one can (in contrast to JDK Hotswap), change Bundle.properties files.
Contents |
Hotswap is not Only About Changing Classes
My ode to true hotswap contained one important observation: Now it is easier to change any class in my program than to modify content of Bundle.properties! As Javeleon author Allan Gregersen convinced me - having the ability to update classes, is just first step, there is much more that needs to be done to make the hotswap real.
Resources
As already noted, resources often need to be updated too. Otherwise you may get new version of a class trying to access ResourceBundle.getString for a key which is not in the outdated version of the bundle. To support reloading of resources, one needs to enhance existing ClassLoaders a bit.
There is no reason for new APIs on Java side. When the JDK Hotswap implemented by Thomas Würthinger is available, you can always tweak all the existing classes (ResourceBundle, ClassLoader, or NetBeans StandardModule, etc.) and hotswap them with a new version that is capable to support the generic updating platform.
Of course, being able to hotswap existing classes like ResourceBundle, creates some form of close API-like dependency between the JDK team and the provider of a real Hotswap platform. This kind of API is also very fragile and can often break (unless the contract is stiffed by using Amoeba techniques) and requires intimate knowledge of the internals of various pieces of JDK or NetBeans.
Still things can work. If there is a need for hotswap, one "bootstraps" by hotswapping important JDK and framework classes first. Then one can start updating the user artifacts as freely as necessary. Only the sky will be the limit.
Caches
Caches are another thing that needs attention. The above mentioned ResourceBundle not only needs to learn about new .properties file being available, but it also needs to clean the previously loaded values from internal caches. Provider of real hotswapping solution needs to be aware of caches like this and needs to invalidate them when necessary.
Getting this work correctly is tricky. Javeleon does this fine job for NetBeans Platform based applications.
Adding new classes
Reloading existing class (as handled by Thomas Hotswap) is easier than adding new classes. There is many classloaders in typical Modular systems. When declaring new class, one shall tell the JVM which classloader shall load it. The JPDA API is not capable of doing this right now.
Still, we can use the trick with hotswapping the core JDK classes and updating them with such possibility. Just load in an enhanced version of ClassLoader and use the newly defined private contract to tell it about the availability of a new class.
Dependencies
Dealing with classloaders is tricky. In system with non-flat classpath described by dependencies (like NetBeans and OSGi) this can be even harder. By changing manifest of individual JAR files, one can influence the actual runtime classpath. This is much more than just changes to class hierarchies, and again, real hotswap system shall work with the container to do this correctly.
Existing Objects
Additional obsticle in a way is existence of long living objects with a state (visual components like forms or main window are quite common in desktop applications). Changing their initialization code does not immediatelly change the already existing components (as the initialization already happened).
To solve this one needs to provide re-entrant initialization - a way to run the initialization code multiple times and then re-execute it each time the defining class changes.
Real Hotswap
Having a way to update classes is essential, but not sufficient. Real hotswap needs to be well integrated into the framework to deal with updates of caches, resources or long living objects created way before first hotswap. NetBeans is glad that most of this work has been provided by Javeleon. Hopefully, when Javeleon and similar solutions will not need to deal with hotswap of classes (as that will be part of JDK), they will have more time to provided even tighter integration their associated framework.
Follow
