| Summary: | [1.5][compiler] Generics related AbstractMethodError that is not given by Sun Java | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Matt Hillsdon <mth-eclipse> | ||||||
| Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | eric_jodet, Olivier_Thomann, philippe_mulet | ||||||
| Version: | 3.4 | ||||||||
| Target Milestone: | 3.4 M6 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
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 |
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).