Javeleon - Revision history

JaroslavTulach at 08:05, 18 February 2011

2011-02-18T08:05:47Z

←Older revision		Revision as of 08:05, 18 February 2011
Line 1:		Line 1:
-	[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}}

JaroslavTulach: /* Real Hotswap */

2011-02-18T07:58:43Z

Real Hotswap

←Older revision		Revision as of 07:58, 18 February 2011
Line 41:		Line 41:
	== 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]]

JaroslavTulach: /* Hotswap is not Only About Changing Classes */

2011-02-18T07:57:09Z

Hotswap is not Only About Changing Classes

JaroslavTulach: /* Dependencies */

2011-02-14T12:29:03Z

Dependencies

←Older revision		Revision as of 12:29, 14 February 2011
Line 31:		Line 31:
	=== [[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 ===

JaroslavTulach: /* Adding new classes */

2011-02-14T12:28:27Z

Adding new classes

←Older revision		Revision as of 12:28, 14 February 2011
Line 27:		Line 27:
	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]] ===

JaroslavTulach: /* Resources */

2011-02-14T12:26:03Z

Resources

←Older revision		Revision as of 12:26, 14 February 2011
Line 9:		Line 9:
	=== 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.
Line 15:		Line 15:
	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 ===

JaroslavTulach at 12:24, 14 February 2011

2011-02-14T12:24:34Z

←Older revision		Revision as of 12:24, 14 February 2011
Line 1:		Line 1:
-	[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}}

JaroslavTulach: /* Adding new classes */

2011-02-14T12:13:51Z

Adding new classes

←Older revision		Revision as of 12:13, 14 February 2011
Line 25:		Line 25:
	=== 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.

JaroslavTulach: /* Hotswap is More than Classes */

2011-02-14T12:13:19Z

Hotswap is More than Classes

←Older revision		Revision as of 12:13, 14 February 2011
Line 3:		Line 3:
	{{#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''.

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

		+	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]].
		+
		+	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 [[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.
		+
		+	=== 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.
		+
		+	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.
		+
		+	=== [[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.
		+
		+	=== 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 [[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.


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

JaroslavTulach at 11:36, 14 February 2011

2011-02-14T11:36:23Z

←Older revision		Revision as of 11:36, 14 February 2011
Line 1:		Line 1:
-	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}}
		+
		+	== [[Hotswap]] is More than 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''.
		+
		+
		+
		+

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

←Older revision		Revision as of 07:57, 18 February 2011
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~~, 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 ===
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]] ~~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.