Community
Participate
Working Groups
Calling the method getClass() inside a generic method returns different results for Sun's javac (up to 6 beta 2) and Eclipse's JDT (3.2). A compileable and warning-free program can NOT be compiled by javac. Example valid for JDT: public <T> Class<? extends T> fooGetClass(final T object) { return object.getClass(); } Corrected version for javac: public <T> Class<? extends T> fooGetClass(final T object) { return (Class<? extends T>) object.getClass(); } Without the cast (Class<? extends T>) javac reports: GetClassTest.java:6: incompatible types found : java.lang.Class<capture of ? extends java.lang.Object> required: java.lang.Class<? extends T> return object.getClass(); Eclipse reports for the javac version an unnecessary cast. Eclipse 3.2 has a function "Clean Up" which removes unnecessary code. It also removes the cast, and makes the code uncompileable for javac. I remember vaguely that the "Java Language Specification" hold an exception which gives Eclipse right. But I'm not sure.
Maxime, Can you verify if this is an identified Sun javac's bug? Thanks
Why did you set this bug severity to critical? You should not have so places where this problem occur and moreover, it is easily workaroundable (just put the cast back after the "Clean Up"). Would you agree to reduce it to normal (or major if you really use the "Clean Up" very often)?
At the moment, I have to change it in 2 of 40'000 LOC. But only because I wrote an auxiliary static method (like the one in the example). So judge yourself how frequent this can appear in a code. I agree for a reduction of the severity as I'm an bug commiter from outside. It's interesting to see that if you let T be a subclass of Number, javac complains in this way: incompatible types found : java.lang.Class<capture of ? extends java.lang.Number> required: java.lang.Class<? extends T> return object.getClass(); So javac makes erasure first. I don't see the point in differenciating between Class<? extends T> (with T extends Number) and Class<? extends Number> if the ereased return type is the type Class. Even if the return value of the method is assignable to Class<? extends Number>, why should there be internaly a restriction? It would be nice to know what counts: 1. Class<? extends T> because this is correct if Java had no erasure 2. Class<? extends [raw type]> because Sun wants it so in javac For me it looks like a bug in javac. If this would be the case, I don't think it was a mistake to fill this bug report. Who would expect that getClass() works wrong?
Should have been more proactive on this one, sorry. See bug 147381 for further comments. *** This bug has been marked as a duplicate of 147381 ***
Verified for 3.3 M1 using build I20060807-2000.
Verified for 3.2.1 using build M20060915-1045
