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
