Community
Participate
Working Groups
The attached code sample has ambiguous javadoc - it's not clear which of the getMax variants the link should be resolved to. Eclipse 3.3M3 correctly identifies the ambiguity, but doesn't have a hint other than removing the link. If it's not resolvable perhaps it should suggest converting it into {@code}? Also the javadoc spec seems to imply that getMax(Iterable ip1) should be more resolvable than getMax(Iterable) - so the 3rd instance shouldn't be ambiguous.
Created attachment 54429 [details] Snippet that produces the problem
Created attachment 54430 [details] Snippet that produces the problem
The JDK documentation sucks for this sort of stuff - otherwise I'd point to what it should be suggesting
Must be a problem in code select over the Java doc link. When I hover of the link I gte the folloing exception: Exception in thread "Text Viewer Hover Presenter" java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.MethodBinding.computeUniqueKey(MethodBinding.java:328) at org.eclipse.jdt.internal.compiler.lookup.Binding.computeUniqueKey(Binding.java:55) at org.eclipse.jdt.internal.codeassist.SelectionEngine.selectFrom(SelectionEngine.java:892) at org.eclipse.jdt.internal.codeassist.SelectionEngine.select(SelectionEngine.java:690) at org.eclipse.jdt.internal.core.Openable.codeSelect(Openable.java:155) at org.eclipse.jdt.internal.core.CompilationUnit.codeSelect(CompilationUnit.java:329) at org.eclipse.jdt.internal.core.CompilationUnit.codeSelect(CompilationUnit.java:323) at org.eclipse.jdt.internal.ui.text.java.hover.AbstractJavaEditorTextHover.getHoverInfo(AbstractJavaEditorTextHover.java:120) at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo(BestMatchHover.java:102) at org.eclipse.jdt.internal.ui.text.java.hover.JavaEditorTextHoverProxy.getHoverInfo(JavaEditorTextHoverProxy.java:69) at org.eclipse.jface.text.TextViewerHoverManager$4.run(TextViewerHoverManager.java:160)
The reason is that the @link #getMax(Iterable) is ambiguous. The javadoc tool doesn't detect it and creates two identical anchors for both methods. We have two ways to fix it. 1) The code selection checks if the binding is a valid binding before trying to open the javadoc. This would end up with no hints for this link. 2) We try to take the closest match if one is set for the problem method. David, I'll let you investigate it.
This is a side effect of fix for bug 155003 to have the method thrown exceptions dumped in unique key... I'll add a check to prevent the NPE...
Created attachment 54494 [details] Proposed patch
Released for 3.3 M4 in HEAD stream. Note for verifier, you need to use build I20061121-1845 to verify that this NPE really happens. As it was (unfortunately) introduced while fixing bug 155003, it does not happen in 3.3 M3...
We should also investigate why code selection is trying to get the key of a problem method binding. In this case the method is ambiguous. David, please comment on this.
Code select return java element as result. These java elements are computed from bindings. Code select can compute the elements from problems bindings for some specific case. Keys are used to build resolved java elements (e.g. ResolvedSourceMethod). The current test case must be supported but the behavior of code select with ambiguous methods isn't perfect and must be improved. I opened another bug for this issue: bug 165900. I close this bug as fixed because the NPE is fixed.
Verified for 3.3M4 with I20061212-0010.
