Community
Participate
Working Groups
Hello, I am using the Eclipse JDT DOM interface to parse and analyse Java projects. In one of the projects I am working with I get the following exception: java.lang.ClassCastException: org.eclipse.jdt.internal.core.Initializer cannot be cast to org.eclipse.jdt.core.IType at org.eclipse.jdt.core.dom.MethodBinding.getUnresolvedJavaElement(MethodBinding.java:238) at org.eclipse.jdt.core.dom.MethodBinding.getJavaElement(MethodBinding.java:231) at org.eclipse.jdt.astview.views.Binding.getChildren(Binding.java:247) at org.eclipse.jdt.astview.views.ASTViewContentProvider.getChildren(ASTViewContentProvider.java:95) at org.eclipse.jdt.astview.views.ASTViewContentProvider.hasChildren(ASTViewContentProvider.java:252) at org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable(AbstractTreeViewer.java:2021) at org.eclipse.jface.viewers.TreeViewer.isExpandable(TreeViewer.java:575) ... I abstracted the problem to the following program: public class Test { Object t; private void testMethod() { t = new Object() { Object o; // put this after the Initialization block // or remove it to avoid error { Object m = new Object() { // try to resolve the binding of // the "new" (ClassInstanceCreation) // and you get the exception }; } }; } } The problem is not only in my own implementation using the DOM API, but you can reproduce it using the Eclipse AST Viewer (http://www.eclipse.org/jdt/ui/update-site). View the class above in the ASTView, select the innermost new Object() and click "Show AST of active editor (F5)" in the ASTView. You will get the exception described. The problem seems to be, that the code in "org.eclipse.jdt.core.dom.MethodBinding.getUnresolvedJavaElement(MethodBinding.java:238)" does not expect to get an Initializer. I could not test the problem in older Eclipse versions. I would be happy if this problem could be fixed as soon as possible. Thank you, Rüdiger
Fix for bug 129584 fixed this problem. See bug 149853 for the same stack trace *** This bug has been marked as a duplicate of bug 129584 ***
Are you sure that you are using 3.3.1?
(In reply to comment #2) > Are you sure that you are using 3.3.1? Well, Eclipse reports in the About Eclipse SDK Dialog Version: 3.3.1.1 Build id: M20071023-1652
(In reply to comment #1) > Fix for bug 129584 fixed this problem. See bug 149853 for the same stack trace > *** This bug has been marked as a duplicate of bug 129584 *** Hello again. Thank you for your fast feedback. :-) I don't think this is a duplicated bug. I was reading the bug reports 129584 and 149853. For 129584, I do not see the relation. 149853 seems somewhat related, but the exception comes from a different line number for a different type. The described problem is fixed in my version of Eclipse. I tested the situation also under Eclipse 3.2.2 (M20070212-1330). There bug 149853 does still exist, and my bug as well. I used the Eclipse AST View 1.1.3 in this case. But the problem described by me still exists, and now I know it was already there in 3.2.2. Could anybody reproduce it? Is it ok, that I marked this bug as "Reopen bug"?
(In reply to comment #4) > I don't think this is a duplicated bug. I was reading the bug reports 129584 > and 149853. This is why I asked what build you are using. If you got the problem with a build post 3.3M1, then this cannot be a duplicate of the bug 129584.
Clear target milestone.
(In reply to comment #6) > Clear target milestone. Thank you!
(In reply to comment #4) > I don't think this is a duplicated bug. I was reading the bug reports 129584 > and 149853. Sorry I went to fast. I tested with the latest 3.4 build and could not reproduce. Since the trace in bug 149853 looked similar (even though for a different type) I assumed that was the same problem. > Could anybody reproduce it? I could reproduce in the 3.3 maintenance stream. Not in HEAD (the 3.4 development stream). I will try to find out what change made it working in 3.4. > Is it ok, that I marked this bug as "Reopen bug"? Yes, you did the right thing.
After investigation, the fix for bug 167357 fixed the problem in HEAD. I'm not sure if we can backport this fix to R3_3_maintenance. We might want to add a workaround instead.
Created attachment 83977 [details] Proposed workaround and regression test Note with this workaround, the returned element doesn't exist, but at least it doesn't throw a ClassCastException. The real fix would be to backport the fix for bug 167357 which I think is too risky.
Asking PMC approval to add this workaround for 3.3.2. This workaround is safe and it avoids the ClassCastException.
+1 for 3.3.2
Workaround and test released for 3.3.2
Jérôme, I would suggest that you also release ASTModelBridgeTest#testMethod11 in HEAD.
Good suggestion. ASTModelBridgeTest#testMethod11 is now released in HEAD. Note that the expected Java element is different from the one in R3_3_maintenance because of bug 167357 that is fixed in HEAD.
The test is here and runs OK. Verified for 3.4 M4 using build I20071211-0010.
Verified for 3.3.2 using M20080123-0800 build
