On 17/04/2018 4:36 AM, 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.

I don't see any conflict there. can_redefine_any_class relates to the sets of classes amenable to redefinition, not to the set of changes that redefinition can make to a given class.

Arguably there could have been individual capabilities for each kind of change, but that seems somewhat extreme to me, unless there are good reasons why only subsets of changes would be reasonable to support. The existing "you can do anything except x, y, z" within the spec for redefineClass is coarse but not unreasonable. It is problematic because the exception list is incomplete but that's a different story.

as well as conflicting with the implementation of SetNativeMethodPrefixes et. al. and the RI in terms of private/final/static.

So two clear cases where the spec should have been updated but wasn't.

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.

Moving the text doesn't change the basic problem that the text and implementation are not in agreement.

David
-----

-Robert

Reply via email to