Expected behavior for annotation property with duplicate value definition

[Rafael Winterhalter]

Hi David,
yes, of course. However, the JVM already yields exceptions upon illegal
constructs, most of the time a class would fail to load through
verification. For annotations, there is a whole tree of exceptions such as
AnnotationTypeMismatchException but this one scenario with two values for a
single property does not seem to be handled but is silently ignored. I
mainly wonder if this other illegal scenario should not be handled in the
same category of throwing an exception. To my knowledge, there is no other
annotation inconsistency that is silently suppressed.
Best regards, Rafael

Am Mi., 5. Mai 2021 um 11:55 Uhr schrieb David Holmes <
david.holmes at oracle.com>:

> Hi Rafael,
>
> On 5/05/2021 6:53 pm, Rafael Winterhalter wrote:
> > Hello,
> >
> > I was wondering if the current OpenJDK behavior should yield an exception
> > or if it is accidental and if so, if it should be altered to avoid
> > surprising behavior. If an annotation:
> >
> > @interface Sample {
> >    String v();
> > }
> >
> > is added to a member where the property 'v' is assigned a value twice,
> the
> > last added value is returned by the reflection API and no error is
> raised.
> > I recently observed this for ASM-generated code where a value was added
> > twice and it led to a longer bug search, but technically this could of
> > course also happen when javac or other language compilers generate code.
> I
> > wonder therefore if this should rather yield an error or if this behavior
> > should be documented somewhere in case that the change would be possibly
> > too disruptive for existing code.
>
> I think you are describing generated bytecode that violates Java
> language rules for Annotation types. That is perfectly legal. The VM's
> notion of what an Annotation type is and how it must behave is much
> broader than that of the Java language.
>
> Cheers,
> David
>
> > I am happy to provide a patch to OpenJDK but wonder what exception should
> > be thrown when reading the property.
> >
> > Best regards, Rafael
> >
>