<div dir="ltr">I've found a similar JEP which might help my case, <a href="https://openjdk.org/jeps/120">JEP 120(Repeating Annotations)</a>: the aim of that JEP was to allow developers to use multiple annotations of the same type on an element, a limitation which was previously being addressed by developers by using container annotations.<br>In the case of this hypothetical JEP, the aim is to allow developers to annotate module directives instead of using the enclosing module definition as a target for annotations that should actually belong to the single directives.<br>I'd like to pinpoint a particular issue, but I'd argue that, as this is a limitation of the language itself, it's impossible to find instances in the ecosystem where this is an issue as the projects that would use this feature can't exist yet.<br>Similarly, I see that in <a href="https://openjdk.org/jeps/104">JEP 104(Type Annotations)</a> the Checker Framework existence is used as a success metric, but that project could be built only after annotations could be applied to types. <br>If I had to find a possible application of this JEP similar to the Checker Framework for JEP 104, I'd say that a build system's dependency management could be built only around the module-info instead of having a seperate file like in the case of Maven or Gradle.<br>I could also research on public code platforms such as GitHub how often annotations that target a module contain attributes that could/should be delegated to a particular directive, assuming the sample size isn't too large and that this data point isn't considered too subjective.<br>I've included this possibility as last as I don't see any indication that any similar work was done for JEP 120, where the only claimed motivation<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Frequently-used idioms of programming with annotations in EE and elsewhere awkwardly use a container annotation just to simulate the ability to apply multiple annotations</blockquote>seems to be purely anecdotal. <br></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 12 nov 2024 alle ore 16:59 Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 12 Nov 2024, at 15:25, Alessandro Autiero <<a href="mailto:alautiero@gmail.com" target="_blank">alautiero@gmail.com</a>> wrote:<br>
> <br>
> <br>
> I'd argue that it's not consistent to allow the members of TypeDeclarations to be annotated, while not doing the same for ModuleDeclaration's.<br>
> I won't argue that this is a large issue: most developers will never write an annotation processor, let alone one that walks through a module, but not being able to annotate the directives that define most of the metadata of a module is a major limitation to the annotation system in this scope.<br>
> I'll also mention the fact that in the javadocs at ModuleElement$DirectiveKind it's clearly stated that new module directives might be introduced in future versions, so supporting annotations might be a "nice to have" for that scenario, but this is purely hypothetical. <br>
<br>
I would suggest to first identify some actual problems that this would solve. I don’t think that an inconsistency *in itself* is enough to justify a feature.<br>
<br>
— Ron<br>
<br>
<br>
</blockquote></div>