Restriction of module redefineability in recent commit
Alan.Bateman at oracle.com
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:
> 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.
More information about the jigsaw-dev