RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods

[Thomas Stüfe]

Hi Serguei,

This is planned to be introduced in jdk 13?

The only concern I have is that both paths (old and new behavior) should be
well tested, and hiding the old behavior behind an optional switch may
reduce its test coverage considerably.

Cheers, Thomas

(p.s. html format does not work well with the OpenJDK mailing list archive,
see
https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027612.html
)

On Thu, Mar 28, 2019 at 1:57 AM serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190328/6f8314ec/attachment-0001.html>