[http://netbeans.dzone.com/nb-javeleon-automatic-update Javeleon] is 100% pure [[Java]] implementation of [[Hotswap]]. On a base level I envision it as complementary to [[Hotswap|DCEVM]] by [[Thomas Würthinger]], just not implemented directly inside [[HotSpot]], but externally via [http://download.oracle.com/javase/6/docs/api/java/lang/instrument/package-summary.html 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.

[http://netbeans.dzone.com/nb-javeleon-automatic-update Javeleon] is 100% pure [[Java]] implementation of [[Hotswap]]. On a base level I envision it as complementary solution to [[Hotswap|DCEVM]] by [[Thomas Würthinger]], just not implemented directly inside [[HotSpot]], but externally via [http://download.oracle.com/javase/6/docs/api/java/lang/instrument/package-summary.html 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.

{{#ev:youtube|sMz8tRP7JV4}}

{{#ev:youtube|sMz8tRP7JV4}}

== Real [[Hotswap]] ==

== Real [[Hotswap]] ==

Having a way to [[Hotswap|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.

Having a way to [[Hotswap|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 provide even tighter integration with their associated framework.

[[Category:Video]]

[[Category:Video]] [[Category:Tools]]

== [[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, there is much more that needs to be done to make the [[hotswap]] ''real''.

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. 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.

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 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]].

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 will be the limit.

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 ===

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]] does this fine job for [[NetBeans]] Platform based applications.

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 is 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.

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.

=== [[Dependencies]] ===

=== [[Dependencies]] ===

Dealing with classloaders is tricky. In system with non-flat classpath described by [[dependencies]] this can be even harder. By changing manifest of individual [[JAR]] files, one can influence (in [[NetBeans]] as well as [[OSGi]]) the actual runtime classpath. This is much more than just changes to class hierarchies, and again, real [[hotswap]] system shall work with the [[NetBeans Runtime Container|container]] to do this correctly.

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 [[NetBeans Runtime Container|container]] to do this correctly.

=== Existing Objects ===

=== Existing Objects ===

Reloading existing class (as handled by Thomas [[Hotswap]]) is easier than adding new classes. There is 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.

Reloading existing class (as handled by Thomas [[Hotswap]]) is easier than adding new classes. There is 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 then just use the newly defined private contract to tell it about the availability of 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.

=== [[Dependencies]] ===

=== [[Dependencies]] ===

=== 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 need 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 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. 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.

There is no reason for new [[API]]s 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]].

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.

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 ===

[http://netbeans.dzone.com/nb-javeleon-automatic-update Javeleon] is 100% pure [[Java]] implementation of [[Hotswap]]. On a base level I envision it as complementary to [[DCEVM|Hotswap]] by [[Thomas Würthinger]], just not implemented directly inside [[HotSpot]], but externally via [http://download.oracle.com/javase/6/docs/api/java/lang/instrument/package-summary.html 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.

[http://netbeans.dzone.com/nb-javeleon-automatic-update Javeleon] is 100% pure [[Java]] implementation of [[Hotswap]]. On a base level I envision it as complementary to [[Hotswap|DCEVM]] by [[Thomas Würthinger]], just not implemented directly inside [[HotSpot]], but externally via [http://download.oracle.com/javase/6/docs/api/java/lang/instrument/package-summary.html 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.

{{#ev:youtube|sMz8tRP7JV4}}

{{#ev:youtube|sMz8tRP7JV4}}

=== Adding new classes ===

=== Adding new classes ===

Reloading existing class (as handled by Thomas [[Hotswap]]) is easier than adding new classes. There is 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.

Reloading existing class (as handled by Thomas [[Hotswap]]) is easier than adding new classes. There is 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 then just use the newly defined private contract to tell it about the availability of 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 then just use the newly defined private contract to tell it about the availability of new class.

{{#ev:youtube|sMz8tRP7JV4}}

{{#ev:youtube|sMz8tRP7JV4}}

== [[Hotswap]] is More than 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!'' Here is where all the fun starts, as having the ability to update classes, is just first step, there is much more that needs to be done to make the [[hotswap]] ''real''.

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''.

[[Category:Video]]

[[Category:Video]]

100% pure [[Java]] implementation of [[Hotswap]]. See http://netbeans.dzone.com/nb-javeleon-automatic-update or watch following video:

[http://netbeans.dzone.com/nb-javeleon-automatic-update Javeleon] is 100% pure [[Java]] implementation of [[Hotswap]]. On a base level I envision it as complementary to [[DCEVM|Hotswap]] by [[Thomas Würthinger]], just not implemented directly inside [[HotSpot]], but externally via [http://download.oracle.com/javase/6/docs/api/java/lang/instrument/package-summary.html 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.

{{#ev:youtube|sMz8tRP7JV4}}

{{#ev:youtube|sMz8tRP7JV4}}

[[Category:Video]]

[[Category:Video]]