Restriction of module redefineability in recent commit

Alan Bateman Alan.Bateman at
Mon Apr 3 19:21:40 UTC 2017

On 03/04/2017 19:49, Rafael Winterhalter wrote:

> I just found out about this change to restrict redefining some modules:
> and I can
> only repeat my warning that this further restriction will make it harder to
> migrate to Java 9 and might break tools in the process. It does neither
> seem to me that a good alternative is offered if opening core modules is
> required to make a Java agent work.
> Is this change intending to freeze classes of java.base or to restrict
> exporting? If so, does this also affect the command line to change the
> properties of certain modules? Was an evaluation done how this change might
> impact existing tools?
I mentioned this in another mail a few minutes ago.

There has always been the notion of unmodifiable classes in both JVM TI 
and java.lang.instrument.  JSR 163 defined a function + method in both 
APIs to test if a class is modifiable and all functions/methods that 
transformed classes could fail. As things stand then you cannot modify 
array  primitive classes, ditto for VM anonymous classes. In the past 
then this was used to deal with interactions with class data sharing 
when classes in the archive could not be modified.

For both API consistency reasons and to allow for cases that we can't 
anticipate now then the new JVM TI functions to update modules should 
allow for the possibility that a module is not modifiable. That should 
not be controversial. There are no unmodifiable modules and there should 
be no impact on agents making use of these functions.


More information about the jigsaw-dev mailing list