[lworld] RFR: 8281463: [lworld] VALUE / PRIMITIVE modifiers should be supported by reflection [v2]

Roger Riggs rriggs at openjdk.java.net
Fri May 27 21:30:11 UTC 2022


On Fri, 27 May 2022 20:21:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add support to java.lang.reflect.AccessFlag ACC_IDENTITY, ACC_VALUE, and ACC_PRIMITIVE.
>> Added corresponding flags to j.l.reflect.Modifier so the "source" of the AccessFlag is the Modifer mask.
>> Remove PERMITS_VALUE; moving the definition used by HotSpot to HotSpot code.
>> 
>> Add comments to java.l.reflect.Modifier suggesting use of AccessFlag instead and limitations.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore AccessFlag SUPER

The design problem with Modifier is that it (will be) acting on a concrete representation of ambiguous information after the mask have been redefined. The bits returned from Class.getModifiers() do not identify as being from that source, similarly Member.getModifiers().

A couple possible avenues going forward:

- Plan the end-of-life of the class Modifier, and also Class.getModifiers() and Member.Modifiers(). Initially, by freezing the semantics and deprecating the class and methods. Arrange that Class.getModifiers() not to return the new bit definitions, so that when they are used with the Modifier class the interpretation is unchanged.
The AccessFlags implementation will need to change to a new perhaps private API to get the flags.

- Enhance the Modifier class and Class.getModifiers() have a mask indicating the alternate use of the low order 16 bits.  A new mask in the upper 16 bits could discriminate between the overloaded masks.
This could avoid the existing Modifier API from misrepresenting the flag bits.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/698



More information about the valhalla-dev mailing list