Instrumentation.redefineModule -- extraPackages argument?
Alan.Bateman at oracle.com
Sat Mar 11 11:13:57 UTC 2017
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
>>> development is definitely not uncommon, and from my experience with
>>> 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.
More information about the jigsaw-dev