On Tue, 7 Feb 2023 14:14:50 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> The relation is that each `Attribute` is applicable in N >> `AttributedElements` and not vice versa. >> For example `ClassModel::attributedElementKind` returns `CLASS` and for >> example >> `Attributes.RUNTIME_INVISIBLE_TYPE_ANNOTATIONS::applicableAttributeKinds` >> returns `Set.of(CLASS, METHOD, FIELD, CODE_ATTRIBUTE, RECORD_COMPONENT)`, so >> we know it is applicable. >> >> However I'll try to re-visit this part of API if needed at all. > > I understand what the API, in its current form, wants to do. IMHO, the same > functionality would be better expressed if the API had a way to say: > > * each attribute has a _target_, where target can be a set of CLASS, METHOD, > ... > * an attribute mapper supports a set of attribute targets > * an attributed element also supports a set of attribute targets > > E.g. the target of the attribute is the concept to model - then > AttributeMapper and AttributedElement just happen to expose a set of > supported targets, which clients can query if needed. I've prepared pull request to jdk-sandbox with complete removal of the AttributedElement.Kind and sent following note to classfile-api-dev at openjdk.org : I would like to propose removal of AttributedElement.Kind across all Classfile API. The AttributedElement.Kind models Attributes “where applicable” and it is a duplication of each Attribute extending ClassElement, MethodElement, CodeElement, etc… Classfile API is not actively using the AttributedElement.Kind except for parsing, where inappropriate AttributedElement.Kind is resolved as UnknownAttribute. Following proposal removes all usages of AttributedElement.Kind from Classfile API: https://github.com/openjdk/jdk-sandbox/pull/48/files Please let me know is there are any objections. ------------- PR: https://git.openjdk.org/jdk/pull/10982
