On 11/03/2017 10:50, Jochen Theodorou wrote:
On 11.03.2017 10:51, Alan Bateman wrote:
On 10/03/2017 16:12, Michael Rasmussen wrote:
:
It might not be the most common scenario, but creating new packages
during
development is definitely not uncommon, and from my experience with
JRebel
and our customers, I can also say that we do see these kind of changes.
So, if the JVM can automatically do it for unnamed modules, why is
this not
a supported redefinition for (named) modules?
If a module is in development or is being significantly refactored to
add/move code to non-exported packages then it really needs to be
re-loaded (in this design then this means re-instantiating a new module
layer, not specific modules).
reloading means the classes will be loaded into a new classloader?
Don´t you think that is overkill for just adding a class in a not yet
existing package - something that was very easy before? I guess you
could always load the new class in the new package into dynamically
created layer. But frankly, that is a new class loader, that requires
you setting relations between layers and all that.
It doesn't having to be a new/different class loader, there is no issue
creating layers of modules where the modules are defined to the same
class loader as modules in other layers.
That will backfire. Does JDK9 even have no notion of removing a layer
and garbage collection on it?
If they are no references then a layer and the modules in the layer will
be GC'ed. There are several stress tests for this.
-Alan
