Community
Participate
Working Groups
Created attachment 90208 [details] Java class demonstrating bug Build ID: M20071023-1652 Steps To Reproduce: Compile and run the attached class. This gives an AbstractMethodError in Eclipse 3.3.1.1. I was surprised to find this works fine in Sun Java 1.6.0_03, to be honest I'd expected a compile error from both. Exception in thread "main" java.lang.AbstractMethodError: GenericsAbstractMethodError$ConcreteFoo.doSomething(Ljava/lang/Object;)V at GenericsAbstractMethodError.feedFoosValueIntoFoo(GenericsAbstractMethodError.java:33) at GenericsAbstractMethodError.testGenericString(GenericsAbstractMethodError.java:46) at GenericsAbstractMethodError.main(GenericsAbstractMethodError.java:51) Running javap on the class files shows that in the Sun Java compiled class there is a public void doSomething(java.lang.Object); method. In the Eclipse case there is no doSomething method on ConcreteFoo (explaining the AbstractMethodError).
Reproduced with HEAD.
Added GenericTypeTest#test1303-1304
Method verifier never issues a bridge method for #doSomething(T) in ConcreteFoo like it should. I believe this comes from the fact it eliminates Foo(String>#doSomething(String) early on (when computing inherited methods), hence it will not consider it any longer afterwards.
Created attachment 92492 [details] Proposed patch with testcase
Released into HEAD for 3.4M6
Verified for 3.4M6 using build I20080324-1300