Instrumentation.redefineModule -- extraPackages argument?

[Alan Bateman]

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