> debugger hot reload
Hey, that's (close to) the traditional Smalltalk introduction-trick! And this has been available since 1.1? How does one concretely do that in Java and why is it not widely known?
Hey, that's (close to) the traditional Smalltalk introduction-trick! And this has been available since 1.1? How does one concretely do that in Java and why is it not widely known?
2. The JDWP protocol lets debuggers redefine nearly anything, but HotSpot doesn't implement the full protocol. In practice many kinds of reload don't work.
3. To fix those issues app frameworks went with classloaders for partial app reloads instead, or reimplemented hotswap logic themselves (see JRebel).
There's no fundamental reason these can't be fixed, and in fact the Espresso JVM fixes both 1 and 2:
https://www.graalvm.org/latest/reference-manual/espresso/hot...
You can write JVM plugins that are invoked after redefinition occurs, allowing you (really your app framework) to do something sensible like partially reload state. And it implements the full protocol, so many more kinds of redefinition work.
Using it is easy. Just install Espresso as your JDK, point your build system at it, then debug your app. Recompiling what attached will cause hot reload.
But the JVM still has a few tricks up its sleeve, e.g. the class loader can dynamically re-load a newly compiled version of a class at runtime - jrebel is a proprietary extension that uses both tricks, but this latter can also be used by spring for hot swapping many parts of a running system.
Basically, in the JVM a class is unique within the class loader, so with a new class loader you can load as many class instances of the same, or slightly different class as you wish.