Bugzilla – Full Text Bug Listing
| Summary: | [1.5][compiler] 3.4RC4 java compiler fails to correctly erase generic type information | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Stephen White <swhite-eclipsebugs> | ||||
| Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> | ||||
| Status: | VERIFIED DUPLICATE | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | philippe_mulet | ||||
| Version: | 3.4 | ||||||
| Target Milestone: | 3.4.1 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Changing the definition of the Operation interface to the following resolves the problem:
interface Operation<In> extends CheckedOperation<In, RuntimeException> {
void op(In o) throws RuntimeException;
}
Despite the fairly simple work-around I still believe this bug to be major (or worse). As this problem occurs at run-time, not compile-time, it is difficult to be sure that all potential occurances of the problem have been caught and the work-around applied. Created attachment 105945 [details]
A zipped plugin project to demonstrate a very similar problem
I found a similar bug with the following code. I've attached a plugin project based on the "Hello, World" template that demonstrates the problem.
public interface Parent<T> {
Activator get(T value) throws RuntimeException;
}
public interface Child<T> extends Parent<T> {
Activator get(T value);
}
public class SampleAction implements IWorkbenchWindowActionDelegate {
...
class Impl<T> implements Child<T> {
@Override
public Activator get(T value) {
return null;
}
}
public void run(IAction action) {
Child<Boolean> c = new Impl<Boolean>();
try {
c.get(true);
} catch (Throwable t) {
t.printStackTrace();
MessageDialog.openInformation(
window.getShell(),
"Test_reimpl_without_throws Plug-in",
t.getMessage());
}
}
}
Dup of bug 238484 Added GenericTypeTest#test1354 for testcase in comment 0 Added GenericTypeTest#test1355 for testcase in comment 1 Added GenericTypeTest#test1356 for testcase in comment 3 This bug will be addressed in 3.4.1, and a patch is going to be available as soon as we restart building 3.4 stream (hopefully this week). *** This bug has been marked as a duplicate of bug 238484 *** Verified for 3.5M1 using I20080805-1307 Verified for 3.4.1 using M20080827-2000. |
Build ID: I20080609-1311 Steps To Reproduce: Create java project based on the enclosed source. Trying to run class 'Bad' fails if the code is compiled using Eclipse 3.4RC4. interface Operation<In> extends CheckedOperation<In, RuntimeException> { void op(In o); } interface CheckedOperation<In, E extends Exception> { void op(In o) throws E; } class ToUpper implements Operation<String> { public void op(String o) { System.err.println(o.toUpperCase()); } } public class Bad { public static void main(String[] args) { new ToUpper().op("hello world 1"); // Works Operation<String> t = new ToUpper(); t.op("hello world 2"); // Doesn't work: Exception in thread "main" java.lang.NoSuchMethodError: Operation.op(Ljava/lang/String;)V } } More information: This example is based on real code from a product we're developing. It compiles and runs with Eclipse 3.3 and when compiled with Sun's javac. After compiling with Eclipse 3.4 it fails with: Exception in thread "main" java.lang.NoSuchMethodError: Operation.op(Ljava/lang/String;)V at Bad.main(Bad.java:9) Using javap shows that Bad.class contains a call: invokeinterface #27, 2; //InterfaceMethod Operation.op:(Ljava/lang/String;)V The String parameter should have been erased to generate the call (as generated by Sun's javac): invokeinterface #7, 2; //InterfaceMethod Operation.op:(Ljava/lang/Object;)V