Review request for JDK-8016880: 42 tests in annot102* fail with compile-time errors

Alex Buckley alex.buckley at oracle.com
Tue Jul 23 14:48:33 PDT 2013


OK, now I see. So both anon.inner classes are legal, fine. #include 
"what Jon said".

Alex

On 7/23/2013 2:09 PM, Eric McCorkle wrote:
> On 07/23/13 16:53, Alex Buckley wrote:
>> Where in any specification is it stated that an annotation in the upper
>> bound of a type parameter affects the semantics of the type variable
>> introduced by the type parameter?
>>
>
> I think you've got what I'm saying backwards.  Prior to this patch,
> javac fails to recognize the following type equality:
>
> Test<T extends S1 & S2> == Test<T extends @Ann S1 & S2> == Test<T
> extends S1 & @Ann S2>
>
> The result of which is that it will not recognize the overriding taking
> place, and the test will not compile.
>
> After the patch, javac will correctly recognize the equality, and the
> test will compile.
>
>> Alex
>>
>> On 7/23/2013 1:49 PM, Eric McCorkle wrote:
>>> On 07/23/13 16:35, Alex Buckley wrote:
>>>> Obviously an annotation anywhere in the upper bound of a type parameter
>>>> should be invisible when it comes to using the type variable introduced
>>>> by the type parameter, say in a method signature.
>>>>
>>>> I presume the test expects errors from both the t1 anon.inner class and
>>>> the t2 anon.inner class ?
>>>
>>> No.  The test will not compile if type annotations on bounds cause the
>>> parent types to be unequal.  If the test compiles, then javac is doing
>>> what (I believe) it's supposed to do.
>>>
>>>>
>>>> Alex
>>>>
>>>> On 7/23/2013 1:15 PM, Eric McCorkle wrote:
>>>>> Hello,
>>>>>
>>>>> Please review this patch, which fixes some JCK failures related to type
>>>>> annotations.
>>>>>
>>>>> The root cause of these is AnnotatedType, which has been scheduled for
>>>>> replacement.
>>>>>
>>>>> The webrev is here:
>>>>> http://cr.openjdk.java.net/~emc/8016880/
>>>>>
>>>>> The bug report is here:
>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016880
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>


More information about the compiler-dev mailing list