JDK-8343886 : make java.lang.classfile.attribute.InnerClassInfo flags access similar to others
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang.classfile
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2024-11-08
  • Updated: 2025-01-27
  • Resolved: 2025-01-27
Related Reports
Duplicate :  
JDK-8342465 - Improve API documentation for java.lang.classfile
Description
ADDITIONAL SYSTEM INFORMATION :
does not apply

A DESCRIPTION OF THE PROBLEM :
The InnerClassInfo interface has both a flags() and a flagsMask() method.  It would be more convenient if the flags() method returned an AccessFlags object, then processing code could be shared with ClassInfo, FieldModel, MethodModel and perhaps others.
Comments
In 8342465, the decision of AccessFlags modeling is explained in the API notes. For most reliable processing, prefer using the flags mask directly whenever possible.
27-01-2025
`AccessFlags` wrapper is a `ClassFileElement`. It is streamed and transformed from relevant `CompoundElement` models (specifically from `ClassModel`, `FieldModel`, and `MethodModel`). `InnerClassInfo` does not decompose to a nested model and so providing its access flags in a form of `ClassFileElement` would be a deviation from the core Class-File API architecture.
11-11-2024
If you look at the corresponding models for java.lang.reflect.AccessFlag.Location, you will find that only class, field, and method have their access flags modeled as a classfile AccessFlags object. All other appearances, namely inner classes, method parameters, and module-related locations all have no AccessFlags object, but their flags are accessed via `Set<AccessFlag> flags` and `int flagMask()` methods instead. This design is because ClassModel, FieldModel, and MethodModel have specific transformation needs: a set or an int is not suitable for pattern matching in transformation, but the custom AccessFlags container interface can be matched against and operated on, and sent to the builders. Note that the AccessFlags factories are removed - this is in anticipation to project Valhalla's change to bring in the identity bit for class modifiers, reusing the currently implicitly default (since Java 8) super flag, so the API can return version-sensitive AccessFlags while the old factories will create error-prone instances. This may be a reason AccessFlags is expanded to other objects, but those objects need their factory methods updated as well; and such a repurpose for other obsolete access flags is indeed unlikely, so we didn't worry about that for other locations. (Also be advised that the super flag does not exist in the inner class modifiers)
10-11-2024
Moved to JDK for further investigations.
10-11-2024