Community
Participate
Working Groups
In a regular Java project paste this class: //--- package test; public class ReferencingClassGetMethods { void test(Class<?> clazz) { clazz.getDeclaredMethods(); } } //--- Put cursor on getDelcaredMethods and search for references. If Xtext is installed (no project nature necessary): the below exception will be thrown. The binding key looks wrong to me - why does it mention the containing class?? Is Xtext creating / provoking this? Perhaps the javaElement passed into TypeURIHelper.getFullURI() is bogus? Exception:java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding cannot be cast to org.eclipse.jdt.internal.compiler.lookup.TypeBinding at org.eclipse.jdt.internal.core.util.BindingKeyResolver.consumeTypeWithCapture(BindingKeyResolver.java:582) at org.eclipse.jdt.internal.core.util.BindingKeyParser.parseTypeWithCapture(BindingKeyParser.java:1012) at org.eclipse.jdt.internal.core.util.BindingKeyParser.parse(BindingKeyParser.java:689) at org.eclipse.jdt.internal.core.util.BindingKeyParser.parse(BindingKeyParser.java:619) at org.eclipse.jdt.internal.core.util.BindingKeyResolver.getCompilerBinding(BindingKeyResolver.java:694) at org.eclipse.jdt.core.dom.CompilationUnitResolver.reportBinding(CompilationUnitResolver.java:1103) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:919) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:588) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:806) at org.eclipse.jdt.core.dom.ASTParser.createBindings(ASTParser.java:1057) at org.eclipse.xtext.common.types.access.jdt.TypeURIHelper.getFullURI(TypeURIHelper.java:342) at org.eclipse.xtext.common.types.ui.query.QueryParticipant.search(QueryParticipant.java:65) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery$2.run(JavaSearchQuery.java:164) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:170) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:91) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
That's what we do in QueryParticipant.search - I'm not sure where some wrong IJavaElement is produced, but the QueryParticipant just passes it on: @Override public void search(ISearchRequestor requestor, QuerySpecification query, IProgressMonitor monitor) throws CoreException { if (!isHandled(query)) { return; } if (monitor == null) { monitor = new NullProgressMonitor(); } try { if (query instanceof ElementQuerySpecification) { ElementQuerySpecification elementQuery = (ElementQuerySpecification) query; IJavaElement element = elementQuery.getElement(); final URI uri = typeURIHelper.getFullURI(element); if (uri != null) createSearchHelper(requestor).search(uri, monitor); } } finally { monitor.done(); } }
still reproducable with 2.10
(happens with newer jdt versions only
@Stephan, for me this looks like a problem on JDT side, org.eclipse.jdt.internal.core.ResolvedBinaryMethod.getKey(boolean) produces a key Ldemo/ReferencingClassGetMethods;&Ljava/lang/Class<!Ljava/lang/Class;{0}*91;>;.getDeclaredMethods()[Ljava/lang/reflect/Method;|Ljava/lang/SecurityException; that later on cannot be parsed correctly by the BindingKeyResolver
(In reply to Christian Dietrich from comment #4) > @Stephan, > > for me this looks like a problem on JDT side, > > org.eclipse.jdt.internal.core.ResolvedBinaryMethod.getKey(boolean) > > produces a key > > Ldemo/ReferencingClassGetMethods;&Ljava/lang/Class<!Ljava/lang/Class;{0}*91; > >;.getDeclaredMethods()[Ljava/lang/reflect/Method;|Ljava/lang/ > SecurityException; > > that later on cannot be parsed correctly by the BindingKeyResolver Do you happen to have the resolved type of the method at hand? OK, we can take a look, but this will have to wait because Java 9 work has priority in JDT for now.
the ResolvedBinaryMethod is the one passed by the search. xtext then tries to get a Binding for that
bulk move out of 4.8
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.
