Added this and prev. suggestion to the JDK-8192936.
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
As written, it explicitly conflicts with the can_redefine_any_class
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
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