On 03/11/2017 12:13 PM, Alan Bateman wrote:
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.
...but then those Module(s) in the new Layer are reachable from
Class(es) defined in them and those Class(es) are reachable from the
common ClassLoader (ClassLoader.classes Vector). Until all classes
defined by the ClassLoader (from various Layer(s)) become unreachable,
none of the Layer(s) can be unloaded.
Am I right? Is package-private ClassLoader.addClass(Class) invoked by VM
to record every loaded class or just every class loaded into unnamed module?
Regards, Peter
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.
