Bugzilla – Full Text Bug Listing
| Summary: | [1.5][compiler] Eclipse compiler behaves differently from javac | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Olivier Thomann <Olivier_Thomann> | ||||||
| Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | hashproduct+eclipse, mpurtill, satyam.kandula | ||||||
| Version: | 3.6 | ||||||||
| Target Milestone: | 3.7 M1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Srikanth, please investigate if this should be a valid test case. *** Bug 320463 has been marked as a duplicate of this bug. *** JLS3 15.8.2 forbids the type named in the class literal expression
from being a parameterized type.
Also, given a generic outer class Outer and a generic inner class
Inner and some two concrete types X and Y, the grammar in section
18.1 (the nonterminal Primary) disallows constructs of the form
- Outer<X>.class
- Outer<X>.Inner.class
- Outer.Inner<X>.class
- Outer<X>.Inner<Y>.class
while allowing Outer.class and Outer.Inner.class, both of which evaluate
to raw typed expressions which is as it should be since class literals
exist only for the underlying raw type and all parameterized versions
share the same literal.
While the grammar itself forbids most misleading & dubious constructs,
the one case where the grammatical proscription does not kick in is the
case seen in this bug and in bug 320463 : When the expression Inner.class
(itself grammatical) is used inside the Outer, the enclosing type is
taken by eclipse to be Outer<T>, instead of being just the raw type
Outer leading to erroneous behavior.
Patch will follow shortly.
Created attachment 174944 [details]
Patch under consideration
All tests pass, Satyam, please review. TIA. Created attachment 175193 [details]
Same patch after synchronizing with HEAD changes.
(In reply to comment #5) > All tests pass, Satyam, please review. TIA. Patch looks good. +1 Released in HEAD for 3.7 M1 Verified for 3.7M1. |
This test case compiles fine with Eclipse, but fails to compile with javac: public class X<T> { public abstract static class Base<S extends Base<S>> { public Base(Class<S> sClass) { Class<S> theClass = sClass; System.out.println(theClass); System.out.println(sClass); } } public class Arr extends Base<Arr> { public Arr() { super(Arr.class); System.out.println(Arr.class); } } public static void main(String[] args) { X<Integer> x = new X<Integer>(); X<Integer>.Arr a = x.new Arr(); System.out.println(a); } } JDK7b91 reports: X.java:13: constructor Base in class Base<S> cannot be applied to given types super(Arr.class); ^ required: Class<X<T>.Arr> found: Class<X.Arr> where T,S are type-variables: T extends Object declared in class X S extends Base<S> declared in class Base 1 error JDK6_20 reports: X.java:13: cannot find symbol symbol : constructor Base(java.lang.Class<X.Arr>) location: class X.Base<X<T>.Arr> super(Arr.class); ^ 1 error javac 1.5.0_24 reports: X.java:13: cannot find symbol symbol : constructor Base(java.lang.Class<X.Arr>) location: class X.Base<X<T>.Arr> super(Arr.class); ^ 1 error