Restriction of module redefineability in recent commit

[Alan Bateman]

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

> I just found out about this change to restrict redefining some modules:
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52cdbd4a5999 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.

-Alan