JVMTI retransformation and addition of private methods
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Mon Apr 16 18:44:35 UTC 2018
Added to the JDK-8192936.
Thanks,
Serguei
On 4/16/18 11:36, Robert Field wrote:
> Rather than reverse engineer the spec from the hotspot implementation...
>
> Capabilities are the mechanism by which the level of functionality is
> defined. Capabilities say what can be done, not what can't.
>
> The wording "The redefinition must not add, remove or rename fields or
> methods, change the signatures of methods, change modifiers, or change
> inheritance. These restrictions may be lifted in future versions." was
> clearly left from an earlier version. Probably should not have been
> there in the first place but certainly should have updated/removed as
> JVMTI evolved.
>
> As written, it explicitly conflicts with the can_redefine_any_class
> capability:
>
> can_redefine_any_class Can modify (retransform or redefine) any
> non-primitive non-array class. See IsModifiableClass.
>
> as well as conflicting with the implementation of
> SetNativeMethodPrefixes et. al. and the RI in terms of
> private/final/static.
>
> i would suggest removing the quoted text and adding to the text for
> the can_redefine_classes capability. Maybe something like:
>
> can_redefine_classes Can redefine classes with
> RedefineClasses, where the class is non-primitive and non-array and
> the redefinition does not add, remove or rename fields or methods,
> change the signatures of methods, change modifiers, or change
> inheritance.
>
> -Robert
>
More information about the serviceability-dev
mailing list