Hotswap
From APIDesign
(→Modular systems and Hotswap) |
(→Debugger) |
||
| Line 9: | Line 9: | ||
In spite of that restriction, [[modularity]] helps developers a lot. Instead of reloading the whole application after change of one service implementation, one can reload just the implementing component/module. Still, all the objects created by the module need to be released and recreated. | In spite of that restriction, [[modularity]] helps developers a lot. Instead of reloading the whole application after change of one service implementation, one can reload just the implementing component/module. Still, all the objects created by the module need to be released and recreated. | ||
| - | == [[ | + | ==Web vs. Desktop == |
| + | |||
| + | For certain kinds of applications it does not matter that all user objects need to vanish during [[Hotswap]]. For example on web this is quite usual. Most of the objects persist only only during one request handling. Throwing them away and pressing F5 to reload a page is easy. | ||
| + | |||
| + | However [[hotswap]]ping the desktop application is more complicated. Nobody can be sure that objects allocated by the [[hotswap]]ed component are not referenced by other parts of the system. True [[hotswap]] system for this kind of environment needs to be able to traverse all the existing objects of of existing component and upgrade them to new ones. Sometimes this is easy (code changes), sometimes it is harder (adding fields, removing fields), sometimes it may be almost impossible (drastic changes to interface hierarchy). | ||
| + | |||
| + | This kind of problems may appear in web applications too (there are often objects that span the life cycle of a request), but they are not as often and as disastrous as in case of desktop. The session wide or application wide objects are usually just config data and they don't change that often anyway. | ||
== [[Thomas Wuerthinger]] == | == [[Thomas Wuerthinger]] == | ||
[[TBD]] | [[TBD]] | ||
Revision as of 21:13, 19 December 2010
Hotswap is the most important technology that makes developers productive. Why people think that PHP makes them more productive than Java? Because it is enough to change a single line of code in your .php file, save it and reload the webpage. Doing the same with Java requires compilation, packaging, deployment. All of this takes ages and is not flexible enough. At least it was not until Thomas Wuerthinger released his patched Hotspot!
Modular systems and Hotswap
In fact, the goal of modular systems is to allow a kind of hotswap. System components are supposed to be installed, enabled, disabled, upgraded or removed from the system on the fly. I believe the modular system succeeded in their mission. They find out the necessary practices to make this happen and limit the goals, so we know what is beyond the scope.
Modularity works fine for services. For implementation of shared interface that some components/modules in the system implement and others look up and use. Really look up and use everytime, you are not allowed to hold a reference to individual implementations. Such implementations are dynamic, change everytime and keeping reference to them may result in two objects implementing the same interface (old and new) not being assignable to each other.
In spite of that restriction, modularity helps developers a lot. Instead of reloading the whole application after change of one service implementation, one can reload just the implementing component/module. Still, all the objects created by the module need to be released and recreated.
Web vs. Desktop
For certain kinds of applications it does not matter that all user objects need to vanish during Hotswap. For example on web this is quite usual. Most of the objects persist only only during one request handling. Throwing them away and pressing F5 to reload a page is easy.
However hotswapping the desktop application is more complicated. Nobody can be sure that objects allocated by the hotswaped component are not referenced by other parts of the system. True hotswap system for this kind of environment needs to be able to traverse all the existing objects of of existing component and upgrade them to new ones. Sometimes this is easy (code changes), sometimes it is harder (adding fields, removing fields), sometimes it may be almost impossible (drastic changes to interface hierarchy).
This kind of problems may appear in web applications too (there are often objects that span the life cycle of a request), but they are not as often and as disastrous as in case of desktop. The session wide or application wide objects are usually just config data and they don't change that often anyway.
Follow
