Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: 1.Compile the code on eclipse (no errors) 2. Run the code on a sun java jvm 3. Blammo! NoSuchMethodError More information: The key here, is that I have an interface that defines a generic method that throws an Exception. An abstract class that implements the interface declares it as method that does not throw the exception. This worked fine in 3.3.2 Here is the source: package mypack; import java.io.IOException; interface TreeVisitor<T,U> { public T visit(U location) ; } interface TreeVisitable<U> { public <T> T visit(TreeVisitor<T,U> visitor) throws IOException ; } abstract class Param implements TreeVisitable<Param> { public final Param lookforParam(final String name) { TreeVisitor<Param, Param> visitor = new TreeVisitor<Param, Param>() { public Param visit(Param location) { return null ; } }; return visit(visitor) ; } public abstract <T> T visit(TreeVisitor<T, Param> visitor); } class StructParam extends Param { public <T> T visit(TreeVisitor<T, Param> visitor) { return null ; } } public class Main { public static void main(String[] args) { StructParam p = new StructParam() ; p.lookforParam("abc") ; System.out.println("done") ; } }
I should mention that when I use the Sun compiler, all works as expected.
If I remove the abstract method declaration of "visit" from "Param", all works well. Although that is a workaround, the fact you are generating code errors that are not caught until *very* well into the runtime is cause for extreme concern IMHO.
Which JRE are you compiling against and which version are you trying to run the code with? Which method call is throwing the NoSuchMethodError (or even just what's on that line)?
Ah sorry, on eclipse I am generating code with a 1.5 compiler compliance level. For runtime: root@egoff:~# java -version java version "1.6.0_05" Java(TM) SE Runtime Environment (build 1.6.0_05-b13) Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing) For compilation: root@build:/# java -version java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) Eclipse 3.3.2, and the 2 versions of sun java play nicely with each other. Eclipse 3.4.0 is the monkey wrench.
root@egoff:~# java -cp /tmp/foo.jar mypack.Main Exception in thread "main" java.lang.NoSuchMethodError: mypack.Param.visit(Lmypack/TreeVisitor;)Lmypack/Param; at mypack.Param.lookforParam(Main.java:19) at mypack.Main.main(Main.java:32)
If I remove the "throws IOException" on visit, the program works ok.
Reproduced with 3.4
Regression got introduced during 3.4M7
Suspect this is related to fix for bug 79798
In presence of "throws IOException", the generated bytecode for method #lookforParam(...) contains invalid method reference: 11 invokevirtual Param.visit(TreeVisitor) : Param [23] instead of: 11 invokevirtual Param.visit(TreeVisitor) : Object [23] (return type did not get erased properly)
The change for bug 79798 is indeed causing grief. 1. It shouldn't create a pseudo method when the most specific exception list is no different from one of the candidate method. This would address the specific scenario of this bug. 2. Moreover, it should NOT create a vanilla MethodBinding, but clone a candidate method binding to preserve the binding semantics, such as erasure etc...
Created attachment 106030 [details] Proposed patch need to test this patch more
Need to backport to 3.4 and 3.3 streams.
Added GenericTypeTest#test135-1353
Created attachment 106050 [details] Better patch Just renamed LessExceptionMethodBinding into MostSpecificExceptionMethodBinding
Created attachment 106052 [details] Patch for 3.3.x
Released for 3.5M1
Released in 3.3.x maintenance branch
(In reply to comment #13) > Need to backport to 3.4 and 3.3 streams. (In reply to comment #16) > Created an attachment (id=106052) [details] > Patch for 3.3.x (In reply to comment #18) > Released in 3.3.x maintenance branch Isn't 3.3.x closed?
I dont know your structure, but if people are downloading 3.3.x then they are downloading a product that does not generate correct java bytecode.
(In reply to comment #0) > This worked fine in 3.3.2 (In reply to comment #20) > I dont know your structure, but if people are downloading > 3.3.x then they are downloading a product that does not > generate correct java bytecode. I thought 3.3.x was fine...?
sorry, I knew mistake to response. :) You are quite right, 3.3.2 did not exhibit the behavior I mentioned, Philip might have found something else.
Created attachment 106055 [details] Patch for 3.4.x
In 3.3.x stream, last official delivery is 3.3.2, which did not have the problem. However, we do provide backport some hot fixes to 3.3.x stream which are then posted on JDT/Core update area (http://www.eclipse.org/jdt/core/r3.3/index.php#UPDATES) when users are asking for it. Given we backported to 3.3.x stream the fix for bug 79798, we need to backport fix for bug 238484, so as not to let this regression show up there as well. I will also contribute this fix to 3.4.1, and release it for integration for 3.5M1. Eric - you can take the first 3.4.1 integration build to get the fix if you want (we shall resume building these next week or so). If it did last too long before materializing, we may want to post you a separate patch to apply to 3.4.0. Let me know your preference.
I can try 3.4.1 when it comes out. thank you
Released for 3.4.1. Fixed
*** Bug 237912 has been marked as a duplicate of this bug. ***
*** Bug 238534 has been marked as a duplicate of this bug. ***
*** Bug 241502 has been marked as a duplicate of this bug. ***
Verified for 3.5M1 using I20080805-1307
Verified for 3.4.1 using M20080827-2000
