Hi Volker,
On 28/03/2019 5:54 pm, Volker Simonis wrote:
Hi Serguei,
can you please detail a little bit on the reasons why you finally
decided to change the implementation to conform to the spec instead of
just updating the spec to endorse a behavior which is there since
quite some time?
The behaviour that has been there "quite some time" only actually works
for very limited usecases. In trying to legitimise the capability and
allow you to add/remove private methods we encountered an ever
increasing spiral of complexity in trying to establish meaningful
semantics. Is it physically possible to implement this? Yes. It is worth
the cost in complexity and maintenance? We concluded not.
We should try to produce a better summary of all the issues.
Cheers,
David
I read trough the comment thread of "JDK-8192936" and it seems to me
that right until your last comment from today, the general conses has
been to change the specs rather than the implementation. I understand
from the various comments in that issue that changing the specs is not
trivial but still doable. Unfortunately, some of the referenced
material in that issue is not available outside Oracle (i.e.
wiki.se.oracle.com) - it would be nice if you could make these
information available in the OpenJDK wiki or somewhere else.
I think that adding private methods is a feature widely used by a lot
of tools and removing it will break them. Deprecating this feature in
a non-LTS release and removing it after "a couple" of (non-LTS)
releases won't help a lot because many productive systems won't use
these releases anyway.
Thank you and best regards,
Volker
On Thu, Mar 28, 2019 at 1:57 AM [email protected]
<[email protected]> wrote:
Hi All,
This is request for comments and potentially reviews for the following CSR:
https://bugs.openjdk.java.net/browse/JDK-8221528
Problem
Now, the implementation of JVMTI RedefineClasses and RetransformClasses allows
to
add/delete private static and private final instance methods in the new class
versions.
It means that current implementation does not follow the JVM TI spec which
explicitly states:
"The redefinition must not add, remove or rename fields or methods, change the
signatures
of methods, change modifiers, or change inheritance."
For details, please, see the spec:
https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RedefineClasses
https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RetransformClasses
The decision was made to align the implementation with the spec.
For reference, please, see the https://bugs.openjdk.java.net/browse/JDK-8192936.
This decision is going to cause some inconveniences to the customers.
Solution
The solution is to introduce a compatibility mode with new command-line VM
option:
-XX:{+|-}AllowRedefinitionToAddOrDeleteMethods
New option will enable old behavior and allow the JVM TI RedefineClasses and
RetransformClasses
to add/delete private static and private final instance methods in the new
class versions.
Without this option the old behavior will be disabled.
New option is deprecated right away.
The plan is to keep it for a couple of releases to allow customers (tool
vendors)
to remove dependency on old behavior from their tools.
Thanks,
Serguei
