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
