Community
Participate
Working Groups
I'm using 3.1RC2. There are two symptoms of this bug, written in CAPITAL LETTERS in steps 4 & 6 below. Steps: 1) Open type javax.swing.DefaultCellEditor. 2) Switch to the Java Browsing perspective. 3) In the Members tab, hilite EditorDelegate and press F4 (Open Type Hierarchy). 4) In the lower pane of the Hierarchy tab, rightclick on setValue(Object) and pick Declarations>>Hierarchy. WRONGLY NONE ARE FOUND. 5) In the upper pane of the Hierarchy tab, doubleclick on any one of EditorDelegate's subclasses. The subclass's source is scrolled into view in the source text editor. 6) In the left margin of the source text editor, click on any of the green triangles appearing at any of the subclass's methods. THE SOURCE TEXT EDITOR FAILS TO SCROLL TO THE SUPERTYPE'S DECLARATION OF THAT METHOD.
Steps for another symptom: Repeat steps 1-2 above. 3) In the Members tab, rightclick on EditorDelegate's constructor and pick References>>Hierarchy. WRONGLY NONE ARE FOUND.
This are two distinct issues. I opened bug 100776 for the search for declaration issue. Moving to Text for the navigation issue (suspect that getJavaElement returns null).
we get the wrong element for the correct method binding when calling IMethodBinding..getJavaElement()
I suspect that search match element handle is not correctly created...
In fact this is not a search problem as it is not involved while clicking on override indicator. In fact, this problem does not seem to come from JDT/Core binding. I've set a breakpoint in OverrideIndicatorManager.open() method at line 106. Now I try to click on override indicator of setValue(Object) method in one of DefaultCellEditor constructor => definingMethod.exist() returns false. I think that's why Dany assign this bug to JDT/Core... However, now try a different scenario: 1) select the setValue(Object) method 2) click on F3 to open editor on anonymous class 3) in this new editor click on override indicator => at my breakpoint, definingMethod.exist() now returns true! methodBinding (result of resolveBinding() on methodDeclaration node), is the same in both scenarios but definingMethodBinding is different => it looks like problem comes from findMethodDefininition(IMethodBinding,boolean) which does not compute correctly method binding from JDT/Core binding key So, put back to JDT/Text component for comment and further investigation
Not sure what the second scenario should prove. definingMethodBinding.getJavaElement() should *not* return the method in the anonymous class but the EditorDelegate.setValue(Object). I will have to debug this with Martin to see whether/why we compute the wrong method binding.
Sorry to have returned this bug a little bit too rapidly... You're right, in my second scenario the element exist but was not correct! I've verified that in first scenario Binding.findMethodDefinition returns correct binding: Ljavax/swing/DefaultCellEditor$EditorDelegate;.setValue(Ljava/lang/Object;)V but getJavaElement() fails to return a valid java element. Put back in JDT/Core land...
Problem is located in TypeBinding.getUnresolvedJavaElement(TypeBinding) In this case, typeBinding argument is a MemberTypeBinding: Member type : EditorDelegate (id=NoId) protected class javax.swing.DefaultCellEditor$EditorDelegate extends java.lang.Object implements : java.awt.event.ActionListener, java.awt.event.ItemListener, java.io.Serializable enclosing type : javax.swing.DefaultCellEditor ... but fileName computed in this method does not reflect it: [=, b, 1, 0, 0, 7, 7, 6, /, D, :, \, /, a, \, /, J, D, K, s, \, /, s, u, n, \, /, 1, ., 5, ., 0, \, /, j, r, e, \, /, l, i, b, \, /, r, t, ., j, a, r, |, j, a, v, a, x, /, s, w, i, n, g, /, D, e, f, a, u, l, t, C, e, l, l, E, d, i, t, o, r, ., c, l, a, s, s] then classFile is: DefaultCellEditor.class [in javax.swing [in D:\a\JDKs\sun\1.5.0\jre\lib\rt.jar [in b100776]]] class DefaultCellEditor and this method returns enclosing type binding instead of member type one...
You can also see problem when looking at the method binding in the AST view: - open the AST view on DefaultCellEditor line 90, ('setValue'), expand method binding or line 278 ('setValue') java.lang.IllegalArgumentException at org.eclipse.jdt.core.Signature.getParameterCount(Signature.java:981) at org.eclipse.jdt.core.Signature.getParameterTypes(Signature.java:1155) at org.eclipse.jdt.core.Signature.getParameterTypes(Signature.java:1194) at org.eclipse.jdt.ui.JavaElementLabels.getMethodLabel(JavaElementLabels.java:490) at org.eclipse.jdt.ui.JavaElementLabels.getElementLabel(JavaElementLabels.java:386) at org.eclipse.jdt.ui.JavaElementLabels.getElementLabel(JavaElementLabels.java:363) at org.eclipse.jdt.astview.views.JavaElement.getLabel(JavaElement.java:55) at org.eclipse.jdt.astview.views.ASTViewLabelProvider.getText(ASTViewLabelProvider.java:66) at org.eclipse.jface.viewers.StructuredViewer.buildLabel(StructuredViewer.java:1877) at org.eclipse.jface.viewers.TreeViewer.doUpdateItem(TreeViewer.java:231) at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:85) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044) at org.eclipse.core.runtime.Platform.run(Platform.java:783) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:148) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:621) at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:434) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044) at org.eclipse.core.runtime.Platform.run(Platform.java:783) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:148) at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:1763) at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:535) at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:514) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:494) at org.eclipse.jface.viewers.AbstractTreeViewer.handleTreeExpand(AbstractTreeViewer.java:948) at org.eclipse.jface.viewers.AbstractTreeViewer$4.treeExpanded(AbstractTreeViewer.java:959) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:179) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) ...
comment 9 issue seems to be related to bug 100549... => set this bug as depending on it
Created attachment 23650 [details] Fix partially fixing the problem This fix partially fixes the problem as now overriden indicator works but only in top level class editor (ie. DefaultCellEditor.class). It still fails in second scenario (ie. in DefaultCellEditor$1.class editor) I've also added a change in SourceTypeBinding.computeUniquekey(boolean) method to try to fix bug 100549 issue but I'm not really sure it is the correct thing to do...
Hope this patch may help a little bit...
In fact, bug 100549 has nothing to do with this one. Removing dependency.
Really removing dependency
Created attachment 23714 [details] Improved patch This patch takes a different approach: it uses the binding's constant pool name to get the class file name.
Created attachment 23723 [details] Another approach In this approach, we ensure that the class file name is always the toplevel type class file name. The patch still needs to handle the case of anonymous and local types (see TODO)
Anyway, the bug existed in 3.0. So this is not a regression. This is a good candidate for 3.1.1
Created attachment 26288 [details] Merged patches from comment 15 and comment 16
Created attachment 26289 [details] Regression test
+1 for 3.1.1
Released fix (slightly modified to handle default binary packages) and regression tests ASTModelBridgeTests#testBinaryMemberTypeFromAnonymousClassFile1() and testBinaryMemberTypeFromAnonymousClassFile2() in both HEAD and R3_1_maintenance branch.
Verified in I20050920-0010 for 3.2M2
Verified for 3.1.1 using M20050923-1430.
