RFR: JDK-8323684: TypeMirror.{getAnnotationsByType, getAnnotation} return uninformative results [v3]

[Joe Darcy]

On Thu, 18 Jan 2024 01:01:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/AnnoConstruct.java line 53:
>> 
>>> 51:  * or deletion without notice.</b></p>
>>> 52:  */
>>> 53: public abstract sealed class AnnoConstruct implements AnnotatedConstruct
>> 
>> @lahodaj or @vicente-romero-oracle , any thoughts on using sealed/non-sealed in javac in this way?
>> 
>> If I don't here back from you on this point, I'll revert use of sealed/non-sealed before pushing. Thanks.
>
> With my `javadoc` hat on, I would hope that `Element` is never `sealed`. But that's a separate issue.

If we had sealed types when JSR 269 was in development, there are at least a few places in the API I would have liked to use them, in particular to seal javax.lang.model.UnknownEntityException to only have in-API subclasses.

Given that the javax.lang.model.{element, type} packages were intended to allow multiple independent implementations, the root interfaces like element couldn't be sealed while achieving that goal.

Inside javac, Type and Symbol could also be declared to be sealed rather than non-sealed, possibly at the cost of listed out all the subclasses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17410#discussion_r1456700924