Community
Participate
Working Groups
I'm experiencing a different behaviour from the two compilers when I try to compile the following code: public class GenericsProblem { public <T> void test(T val) { GenericsProblem gp = new GenericsProblem(); // this is fine with both Class<? extends GenericsProblem> cl2 = gp.getClass(); // This fails on Sun's compiler Class<? extends T> cl = val.getClass(); } } When I compile with Eclipse everithing compile fine, if I compile with Sun compiler, the last instruction produce a compiler error that says that the types are incompatible. I think that the Sun compiler is incorrect because if the first class assignment passes, the second should pass as well because it seems that Object is a special class that is inherently generics.
Tried with quite a few SUN javac versions without any problem. Which version of javac do you refer to?
(In reply to comment #1) > Tried with quite a few SUN javac versions without any problem. > Which version of javac do you refer to? This is what I get compiling the class: C:\ADI_VSFZ\java\JDK15~1.0_0\bin>java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) C:\ADI_VSFZ\java\JDK15~1.0_0\bin>javac GenericsProblem.java GenericsProblem.java:6: incompatible types found : java.lang.Class<capture of ? extends java.lang.Object> required: java.lang.Class<? extends T> Class<? extends T> cl = val.getClass(); ^ 1 error
Reproduced, thanks.
(In reply to comment #3) > Reproduced, thanks. I filed the same bug to Sun, you may be interested: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6439653
This indeed is a bug in the Eclipse compiler, which did not force erasure of type parameter.
Added GenericTypeTest#test1007. Fixed Released for 3.2.1 (TARGET_321) Released for 3.3 (HEAD)
Created attachment 44809 [details] Proposed patch
Released for 3.3 M1 (HEAD)
*** Bug 150294 has been marked as a duplicate of this bug. ***
*** Bug 151677 has been marked as a duplicate of this bug. ***
So according to http://java.sun.com/javase/6/docs/api/java/lang/Object.html#getClass() and some other reports Eclipse will copy Sun's version of ereasing the type and if the generic method variable T extends Number, then getClass() will return Class<? extends Number> and not Class<? extends T> *inside* a method! (please repeat this again for you!) This may solve this bug. But this is a sad decision for generics in Java, as there an additional inconsistency leading to not understandable code, because erasure dominates everything. But why is then List<T> will all possible Ts, even the unerased, allowed? Why is this supported to be future compatible but getClass() for generic method variables must do this acrobatics? Can somebody explain that to me? When generics will be finished, getClass() will return Class<? extends T> and not this provisoric solution.
Verified for 3.3 M1 using build I20060807-2000.
Re: comment 11 This behavior is enforced by the official Java language spec. Until the spec is revised, such a deviation is considered as a bug in a particular compiler implementation. AFAIK, generics are finished. Please argue with the langage specification owners for them to revise it. We cannot change it unilaterally.
Verified for 3.2.1 using build M20060908-1655
(In reply to comment #6) > Added GenericTypeTest#test1007. > Fixed > > Released for 3.2.1 (TARGET_321) > Released for 3.3 (HEAD) > This is working great in Eclipse 3.2.1! Thanks Philippe!!
