On Mon, 27 Jun 2022 20:26:52 GMT, Joe Darcy <da...@openjdk.org> wrote:
> JDK-8289106: Add model of class file versions to core reflection Sending this enum to model class file format versions out for some review comments before starting to write the tests and CSR, etc. The class file format has a rich structure that evolves over time. That evolution includes adding access flags (as modeled by the recently-added java.lang.reflect.AccessFlag enum) as well as JVM attributes (not currently modeled in core reflection). The current docs in the ClassFileFormatVersion enum partially recount the changes in each version; more of the history is encoded in the various tables in JVMS, such as 4.4-B, 4.4-C, and 4.7-B. The intention at this point is not have ClassFileFormatVersion fully model and describe the class file evolution, although that information is of use to some clients and may be added in the future. Given access flags and a notion of class file format versioning, a natural question to be able to answer is "in what class file format versions is this access flag supported and on what structures?" Abstractly, there are a variety of ways that information could be encoded included: public static boolean isSupported(AccessFlag, AccessFlag.Location, ClassFileFormatVersion) public static Set<Location> locations((AccessFlag, ClassFileFormatVersion) The current version in the PR uses a locations(ClassFileFormatVersion) instance method defined on AccessFlag instead. This design puts the primacy on the AccessFlag dimension, but it would be possible to transpose this and make the class file format the prime factor instead (i.e. ClassFileFormatVersion.supportedFlags(AccessFlag.Location)) or even AccessFlag.Location. ------------- PR: https://git.openjdk.org/jdk/pull/9299
