Community
Participate
Working Groups
Steps to reproduce: Open class(!) file org.eclipse.core.internal.jobs.JobListeners and hover the method notify in line 29: private final IListenerDoit aboutToRun = new IListenerDoit() { @Override public void notify<hover with mouse here>(IJobChangeListener listener, IJobChangeEvent event) { listener.aboutToRun(event); } }; Then the error below is logged. eclipse.buildId=4.5.0.I20150430-1445 java.lang.NullPointerException at org.eclipse.jdt.internal.core.util.BindingKeyResolver.consumeLocalType(BindingKeyResolver.java:320) at org.eclipse.jdt.internal.core.util.BindingKeyParser.parseInnerType(BindingKeyParser.java:795) at org.eclipse.jdt.internal.core.util.BindingKeyParser.parse(BindingKeyParser.java:636) at org.eclipse.jdt.internal.core.util.BindingKeyParser.parse(BindingKeyParser.java:618) at org.eclipse.jdt.internal.core.util.BindingKeyResolver.getCompilerBinding(BindingKeyResolver.java:675) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:942) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:586) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:802) at org.eclipse.jdt.core.dom.ASTParser.createBindings(ASTParser.java:1057) at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getHoverBinding(JavadocHover.java:814) at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getInfoText(JavadocHover.java:768) at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getHoverInfo(JavadocHover.java:716) at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.internalGetHoverInfo(JavadocHover.java:639) at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getHoverInfo2(JavadocHover.java:631) at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:163) at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:129) at org.eclipse.jdt.internal.ui.text.java.hover.JavaEditorTextHoverProxy.getHoverInfo2(JavaEditorTextHoverProxy.java:85) at org.eclipse.jface.text.TextViewerHoverManager$4.run(TextViewerHoverManager.java:166) Could not create binding from binding key: Lorg/eclipse/core/internal/jobs/JobListeners$3;.notify(Lorg/eclipse/core/runtime/jobs/IJobChangeListener;Lorg/eclipse/core/runtime/jobs/IJobChangeEvent;)V#event
New Gerrit change created: https://git.eclipse.org/r/48222
This problem is triggered by the changes in bug 403917, but the bug is in BindingKeyResolver itself, which simply expects that a binding key for a local type must be from source. (In reply to Eclipse Genie from comment #1) > New Gerrit change created: https://git.eclipse.org/r/48222 This change is a little band-aid which simply causes BindingKeyResolver to answer null if it's lacking parsed sources. In this situation the JavadocHover will simply fall back to the "old" element based variant.
The band-aid isn't likely to make it for Mars.
*** Bug 471752 has been marked as a duplicate of this bug. ***
@Jay, we have another incompleteness in BindingKeyResolver. Do you think we should / can properly resolve this, i.e., allow BindingKeyResolver to find a binding for a local (anonymous) type without parsed sources? Looking at this message: Could not create binding from binding key: Lorg/eclipse/core/internal/jobs/JobListeners$3;.notify(Lorg/eclipse/core/runtime/jobs/IJobChangeListener;Lorg/eclipse/core/runtime/jobs/IJobChangeEvent;)V#event it seems as if we simply need to retrieve the binding for o.e.c.i.jobs.JobListeners$3, but this doesn't actually match the implementation of LocalTypeBinding.computeUniqueKey(boolean). Hm? Otherwise, we should at least go for the band-aid from https://git.eclipse.org/r/48222
(In reply to Stephan Herrmann from comment #5) > @Jay, we have another incompleteness in BindingKeyResolver. Do you think we > should / can properly resolve this, i.e., allow BindingKeyResolver to find a > binding for a local (anonymous) type without parsed sources? I don't know why, but I can't reproduce this on master. Something changed? From your description of the problem, though, I am fine with the patch you have proposed.
(In reply to Jay Arthanareeswaran from comment #6) > (In reply to Stephan Herrmann from comment #5) > > @Jay, we have another incompleteness in BindingKeyResolver. Do you think we > > should / can properly resolve this, i.e., allow BindingKeyResolver to find a > > binding for a local (anonymous) type without parsed sources? > > I don't know why, but I can't reproduce this on master. Something changed? You need to enable null annotations to enter any code paths related to bug 403917, maybe that's the difference? > From your description of the problem, though, I am fine with the patch you > have proposed. Thanks, I'll push the band-aid for M1 and revisit for a more complete solution during M2+
Gerrit change https://git.eclipse.org/r/48222 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=d3b637377447f913b7000084f8fd9e55ccfded7f
(In reply to Stephan Herrmann from comment #7) > You need to enable null annotations to enter any code paths related to bug > 403917, maybe that's the difference? Indeed, sorry about that.
Moving out to M4.
Ran out of time for M4.
Bulk move: too late for 4.6 M7. Very likely has to be moved out of 4.6 entirely.
bulk move out of 4.8
Bulk move out of 4.9
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
