Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 427380

Summary: [1.8][compiler] Repeated type annotations on generic method declaration not detected
Product: [Eclipse Project] JDT Reporter: Markus Keller <markus.kell.r>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: minor    
Priority: P3 CC: manju656, noopur_gupta, srikanth_sankaran
Version: 4.4   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard: stalebug

Description Markus Keller CLA 2014-02-04 10:50:30 EST
The example below deviously puts the type annotation "@A" on foo()'s return type in two possible positions:

1. in the method declaration's modifiers list
2. directly on the return type

===========================================================

package jsr308.bug.generic;

import java.lang.annotation.*;

@Target({ElementType.TYPE_USE/*, ElementType.METHOD*/})
@Retention(RetentionPolicy.RUNTIME)
@interface A { }

public class Test {
    public @A <T> @A int foo() {
        return 0;
    }
    
    public static void main(String[] args) throws Exception {
        Annotation[] annos = Test.class.getMethod("foo").getAnnotations();
        System.out.println(java.util.Arrays.asList(annos));
        Annotation[] rannos = Test.class.getMethod("foo").getAnnotatedReturnType().getAnnotations();
        System.out.println(java.util.Arrays.asList(rannos));
    }
}

=====================================================

Both positions are actually legal. But the problem is that @A is not a repeatable annotation. And even when I mark it as @Repeatable(AContainer.class) with 

@Target({ElementType.TYPE_USE})
@Retention(RetentionPolicy.RUNTIME)
@interface AContainer {
    A[] value();
}

, then the "@A <T> @A" on both sides of the type parameter <T> are not properly combined into an AContainer annotation:

Exception in thread "main" java.lang.annotation.AnnotationFormatError: Duplicate annotation for class: interface jsr308.bug.generic.A: @jsr308.bug.generic.A()
	at sun.reflect.annotation.TypeAnnotationParser.mapTypeAnnotations(TypeAnnotationParser.java:361)
	at sun.reflect.annotation.AnnotatedTypeFactory$AnnotatedTypeBaseImpl.<init>(AnnotatedTypeFactory.java:139)
	at sun.reflect.annotation.AnnotatedTypeFactory.buildAnnotatedType(AnnotatedTypeFactory.java:65)
	at sun.reflect.annotation.TypeAnnotationParser.buildAnnotatedType(TypeAnnotationParser.java:79)
	at java.lang.reflect.Executable.getAnnotatedReturnType0(Executable.java:583)
	at java.lang.reflect.Method.getAnnotatedReturnType(Method.java:633)
	at jsr308.bug.generic.Test.main(Test.java:24)
Comment 1 Srikanth Sankaran CLA 2014-02-04 11:42:57 EST
Thanks Markus.

This one could be tricky to fix. Code generation happens from AST where the
annotations sit in different locations. An integrated annotation processor
should find the bindings correctly reflecting the container, but that is neither
here nor there, since the class file is FUBAR.

I don't think we want this for GA. In fact I would wait for some end user report
before acting on it.
Comment 2 Markus Keller CLA 2014-02-06 12:43:25 EST
The type annotation after the type parameter declaration is not even legal according to the current grammar:
http://mail.openjdk.java.net/pipermail/type-annotations-spec-comments/2014-February/000055.html

I agree the problem is minor.
Comment 3 Eclipse Genie CLA 2020-04-06 19:39:04 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.