Community
Participate
Working Groups
Using 3.6M6 but also happened with 3.4.2 While investigating bug 305870, I got a NPE while searching for all annotation references in the rt.jar of JRE 6.0. Note that sources must be attached to the jar to get the exception... Here's the stack trace: java.lang.NullPointerException at org.eclipse.jdt.internal.core.search.matching.MatchLocator.newTypeReferenceMatch(MatchLocator.java:1537) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.newTypeReferenceMatch(MatchLocator.java:1546) at org.eclipse.jdt.internal.core.search.matching.TypeReferenceLocator.matchReportReference(TypeReferenceLocator.java:327) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2228) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2161) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2657) at org.eclipse.jdt.internal.core.search.matching.MemberDeclarationVisitor.visit(MemberDeclarationVisitor.java:274) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.traverse(TypeDeclaration.java:1304) at org.eclipse.jdt.internal.compiler.ast.QualifiedAllocationExpression.traverse(QualifiedAllocationExpression.java:484) at org.eclipse.jdt.internal.compiler.ast.FieldDeclaration.traverse(FieldDeclaration.java:288) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2424) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2644) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2669) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2384) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1645) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1050) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1096) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1228) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:239) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:523) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:613)
Created attachment 162301 [details] JDT/UI patch to get access to all the constants in the Java Search page This patch, applied on the org.eclipse.jdt.ui project (v20100316-0800), let user to access and modify all existing Java Search constants in the Java Search page.
To reproduce: 1) use the attached JDT/UI patch, 2) launch a brand new runtime workspace using JRE 6.0, 3) create a Java project 4) click on the 'Search' button in the toolbar 5) set-up the Java Search page as follows: a) Search string: * b) Search for: Annotation c) Limit To: References d) Match mode: Exact e) Search in: all check-boxes selected f) Scope: Workspace 6) Click on Search => you should get an Error dialog 'Problem Occurred' saying that an internal error occurred during 'Java Search'. NPE In the Error log, you should retrieve the stack trace posted in comment 0...
Satyam, After having a look on the offending match with Olivier, we agreed on the solution to add a null check to avoid the NPE. However, Olivier think that as createHandle(AbstractMethodDeclaration, IJavaElement) can return null in certain circumstances, we must ensure that similar null checks are done for all other places where this method is called. Please prepare a patch implementing these null checks and I'll review it. Thanks
In fact, this applies to all createHandle(..) method calls. Since they can return null, we should handle it in the caller.
When the search logic doesn't find the required method in the known classes, other related classes are looked for. When there are no methods in that class file, the other related classes are not being looked at and hence the method handle is not getting created -- As, they are no null checks around the annotations, we are getting this NPE. Javac is generating an inner class with the name className$1 without any methods when there is an inner enum. This is causing the search logic to break!
Created attachment 162740 [details] Proposed patch In this patch, I have made the changes to check for the inner classes even if the first class does not have methods. I have also put a couple of null checks at two places that I found appropriate - I could manage to get the test case by adding a new method in the source code after the class files are generated. I did not put null checks for the other createHandle()'s as I don't think we will run into an NPE. I could not manage to get the testcase even by modifying the source code after the class files are generated.
Created attachment 162741 [details] Jar for the added test
(In reply to comment #6) > Created an attachment (id=162740) [details] > Proposed patch > Very good job Satyam! Having a test case for this is a real good thing :-)
Frederic has released the patch on HEAD
Verified for 3.6M7 using I20100425-2000
