RFR: 8294982: Implementation of Classfile API [v12]

[Maurizio Cimadamore]

On Tue, 7 Feb 2023 12:59:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Still, there seems to be a modelling issue here. The property of "where could this attribute go" is a property of the attribute. Of course, for usability reason, an AttributedElement might expose a predicate saying "I only accept attributes of these kinds". But it seems to me as if the API has this relationship backwards, due to _where_ the Kind interface is being defined. I think if `Kind` was defined in `AttributeMapper` it would be a tad easier to understand. And, perhaps, the `attributedElementKind` name should be changed to something like `applicableAttributeKinds` or something like that.
>
> 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.

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

PR: https://git.openjdk.org/jdk/pull/10982