Javeleon
From APIDesign
(→Dependencies) |
(→Hotswap is not Only About Changing Classes) |
||
| Line 5: | Line 5: | ||
== [[Hotswap]] is not Only About Changing Classes == | == [[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 | + | 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 the first step. There is much more that needs to be done to make the [[hotswap]] ''real''. |
=== Resources === | === 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 ''ClassLoader''s a bit. | + | 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 yet in the outdated version of the bundle. To support reloading of resources, one needs to enhance existing ''ClassLoader''s a bit. |
| - | There is no reason for new [[API]]s on [[Java]] side | + | There is no reason for new [[API]]s on [[Java]] side as soon as the [[JDK]] [[Hotswap]] implemented by [[Thomas Würthinger]] is available. Then the system 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 ''real'' [[hotswap]] of any custom code and resources. |
| - | 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 | + | 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 binary patching [[API]] is 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 | + | Still things can work. If there is a need for [[hotswap]], one ''bootstraps'' by [[hotswap]]ping important [[JDK]] and framework classes first. Then one can start updating the user artifacts as freely as necessary. Only the sky becomes the limit. |
=== Caches === | === Caches === | ||
| Line 21: | Line 21: | ||
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 [[hotswap]]ping solution needs to be aware of caches like this and needs to invalidate them when necessary. | 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 [[hotswap]]ping solution needs to be aware of caches like this and needs to invalidate them when necessary. | ||
| - | Getting this work correctly is tricky. [[Javeleon]] | + | Getting this work correctly is tricky. [[Javeleon]] comes with bunch of hooks like this for [[NetBeans]] Platform based applications. |
=== Adding new classes === | === Adding new classes === | ||
| - | Reloading existing class (as handled by Thomas [[Hotswap]]) is easier than adding new classes. There | + | Reloading existing class (as handled by Thomas's [[Hotswap]]) is easier than adding new classes. There are many classloaders in typical [[Modular system]]s. 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 [[hotswap]]ping 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. | Still, we can use the trick with [[hotswap]]ping 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. | ||
Revision as of 07:57, 18 February 2011
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 the 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 yet 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 as soon as the JDK Hotswap implemented by Thomas Würthinger is available. Then the system 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 real hotswap of any custom code and resources.
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 binary patching API is 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 becomes 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 comes with bunch of hooks like this for NetBeans Platform based applications.
Adding new classes
Reloading existing class (as handled by Thomas's Hotswap) is easier than adding new classes. There are 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
