Hi Volker,
On 3/28/19 03:15, David Holmes wrote:
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.
Thanks, David, for replying to this question.
I agree, we have to provide a better summary of all the issues we
discovered.
Shortly, the capability to allow to add/remove private methods has
non-local impact
on VM mechanisms such as nestmates, methods resolution, MethodHandle's
and reflection.
The red flag is that we were looping in discovering more problems than
were initially expected.
Yes, fixing those is doable but will introduce extra complexity and
maintenance cost.
We concluded that it is not worth it.
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.
This is interesting point.
We may need to think a little bit more on this.
Thank you for your questions and concerns!
It is what we hoped for.
Thanks,
Serguei
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
