ArC - enhance the generated annotation literal classes

[mkouba]

Description

Currently, all generated annotation literals extend javax.enterprise.util.AnnotationLiteral. This is suboptimal as all functionality (including equals() and hashCode()) is implemented via the reflection API.

Implementation ideas

No response

[quarkus-bot[bot]]

/cc @manovotn

[mkouba]

In fact, this would only help if equals() is called upon an instance of a generated annotation literal. If it's called upon an instance of an javax.enterprise.util.AnnotationLiteral subclass then the reflection would be used anyway.

[manovotn]

In fact, this would only help if equals() is called upon an instance of a generated annotation literal. If it's called upon an instance of an javax.enterprise.util.AnnotationLiteral subclass then the reflection would be used anyway.

So which annotations do we generate literals for? I.e. what impact would this change have for an application? Because most of CDI annotations have literals predefined and those are subclasses of javax.enterprise.util.AnnotationLiteral.

[mkouba]

So which annotations do we generate literals for?

Qualifiers and interceptor bindings, and also annotations of an injection point that resolves to a dependent bean that injects InjectionPoint metadata :-). Typical runtime examples are BeanAttributes.getQualifiers() and Interceptor.getInterceptorBindings().

[Ladicek]

I've recently implemented a generator of equals, hashCode and toString in Gizmo, so I think I have the necessary experience to do the same here. I can't just use the equals generator in Gizmo, because that assumes identical class, and the hashCode needs to be consistent with what AnnotationLiteral does, but it will be very similar. The toString generator could be used directly, but I'll rather copy it and improve a few things to make it closer to AnnotationLiteral.toString output.