Debugging applications - OSGi in Action - page 268

Figure 8.6 HotSwap failure updating DefaultShape
worse, if you decide to ignore this error message and continue, you still get the same
exception as before when painting shapes.
Alternative implementations of HotSwap do support adding methods. You can
find one such implementation in the IBM JDK ( www.ibm.com/developerworks/java/
jdk/ ). If you debug the same example using IBM Java 6 as the target runtime (remem-
bering, of course, to first revert the setColor() method back to the broken version),
you can successfully fix the problem without restarting the process. Figure 8.7 con-
firms that even after using HotSwap to squish the bug, both the old and new paint
examples continue to work on the IBM JDK .
Although you eventually managed to use HotSwap to fix the problem in your bun-
dle, this isn't exactly what you want, because all versions of DefaultShape were
updated. By chance, this didn't affect the old paint example because you were adding
a completely new method. It has no effect on the old application and sits there
unused. But what if you wanted to change a method that was tightly coupled to exist-
ing code? You could end up fixing one version only to find out you'd broken all the
others by unintentionally upgrading them with the new logic. This may not be a big
deal during development, because you'll probably be focusing on one version at a
time; but can you do better when debugging OSG i applications in the field?