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
