Community
Participate
Working Groups
In medium-complexity hierachies of generics, the compiler generates semanticaly incorrect class files and doesn't detect the same errors as Sun's Javac. Attachment contains the problematic case, run the "Test" class. It is a hierachy made of a DiscreteOrder<E extends Comparable<E>> interface, requiring "next" and "previous" methods (signature like public E next(E element)). IntegerOrder implements DiscreteOrder<Integer>, and IntegerOrder2 extends IntegerOrder. IntegerOrder is correct with the Sun's Javac but is badly generated with the Eclipse's one : calling next after a cast to "DiscreteOrder<Integer>" throws a AbstractMethodError. IntegerOrder2 corrects the bug of Eclipse but generate an error with the Sun's Javac. It adds a new "next" method : public Comparable next(Comparable element) { return next((Integer) element); } Badder, if I remove the "previous" method from DiscreteOrder, IntegerOrder become correct with Eclipse's compiler too (IntegerOrder2, which is wrong, keeps looking clean to Eclipse's compiler). Hope this helps.
Created attachment 16538 [details] The project demonstrating the problems
With latest set of changes, your testcase prints: *** public void Test.test1(): success *** public void Test.test2(): success *** public void Test.test3(): success *** public void Test.test4(): success
This was likely due to our mishandling of generic cast some situations, which we had to resolve when implementing autoboxing. Added regression test: GenericTypeTest#test435. Fixed
Sorry, there's something else but which is not a blocker bug : the IntegerOrder2 class souldn't compile because, as javac said : [javac] src/orders/impl/IntegerOrder2.java:10: name clash: next(java.lang.Comparable) in orders.impl.IntegerOrder2 and next(E) in orders.DiscreteOrder<java.lang.Integer> have the same erasure, yet neither overrides the other [javac] public class IntegerOrder2 extends IntegerOrder { [javac] ^ [javac] 1 error So the test case souldn't compile since it depends on IntegerOrder2.
Reopening for further investigation.
Kent - pls investigate. Also fix up test case in generic type test in the end (we want 2 tests, one checking no ClassCastException, and one checking problem method verifier error is issued).
I'm not convinced that javac is correct in producing a name clash error. Take this case: interface I<E extends Comparable<E>> { public void test(E element); } class A implements I<Integer> { public void test(Integer i) {} } class B extends A { public void test(String i) {} } There is no name clash error on B.test(String) since its not overriding A.test (Integer), which implements I.test(E) correctly. It should be possible for subtypes to define a method with the same name as its superclass' method but a different argument type, even if it does equal the erasure of an inherited interface method (assuming its implemented by the correct superclass).
I would tend to agree that IntegerOrder2 defines unrelated methods as well. Can you log a separate bug for further investigation on last issue ? And close this one as fixed ?
Opened bug 81332 to track the possible name clash problem.
Verified in 200412160010
