Comment 1 Stephan Herrmann 2018-11-04 14:56:39 EST

A small project to reproduce the error would be awesome.

Comment 2 Steven Schlansker 2019-02-19 16:07:27 EST

I am suffering what may be a related issue, but during a Java Search on Eclipse 4.11M2.  "An internal error occurred during 'Java Search'"  Very frustrating, I cannot search any projects anymore!  The stack trace looks almost identical.

java.lang.NullPointerException
	at java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:655)
	at java.base/java.lang.StringBuffer.append(StringBuffer.java:399)
	at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.shortReadableName(ParameterizedTypeBinding.java:1267)
	at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.shortReadableName(ParameterizedTypeBinding.java:1259)
	at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.invalidMethod(ProblemReporter.java:4576)
	at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:797)
	at org.eclipse.jdt.internal.compiler.ast.ASTNode.resolvePolyExpressionArguments(ASTNode.java:712)
	at org.eclipse.jdt.internal.compiler.ast.MessageSend.findMethodBinding(MessageSend.java:961)
	at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:775)
	at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:1057)
	at org.eclipse.jdt.internal.compiler.ast.Block.resolveUsing(Block.java:138)
	at org.eclipse.jdt.internal.compiler.ast.TryStatement.resolve(TryStatement.java:1189)
	at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:125)
	at org.eclipse.jdt.internal.compiler.ast.ForStatement.resolve(ForStatement.java:411)
	at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:641)
	at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:316)
	at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:551)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1262)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1387)
	at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:652)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:2008)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1336)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1377)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1496)
	at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:112)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:250)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:595)
	at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:670)
	at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:178)
	at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:95)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Eclipse IDE for Java Developers
Version: 2019-03 M2 (4.11.0 M2)
Build id: 20190207-1445
OS: Linux, v.4.20.8-200.fc29.x86_64, x86_64 / gtk 3.24.1, WebKit 2.22.6
Java version: 11.0.2

Reading a bit into the `org.eclipse.jdt` source code, I wonder if the problem may be that the shortReadableName computation does:

nameBuffer.append(this.type.sourceName);

Not all types have a name -- an anonymous class for example -- and the StringBuffer.append(char[]) is *not* null-safe:

public AbstractStringBuilder append(char[] str) {
    int len = str.length;
    ensureCapacityInternal(count + len);
    appendChars(str, 0, len);
    return this;
}

Comment 3 Stephan Herrmann 2019-02-19 18:23:21 EST

(In reply to Steven Schlansker from comment #2)
> I am suffering what may be a related issue, but during a Java Search on
> Eclipse 4.11M2.  "An internal error occurred during 'Java Search'"  Very
> frustrating, I cannot search any projects anymore!  The stack trace looks
> almost identical.
> 
> java.lang.NullPointerException
> 	at
> java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:
> 655)
> 	at java.base/java.lang.StringBuffer.append(StringBuffer.java:399)
> 	at
> org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.
> shortReadableName(ParameterizedTypeBinding.java:1267)
> ...
> Eclipse IDE for Java Developers
> Version: 2019-03 M2 (4.11.0 M2)
> Build id: 20190207-1445
> OS: Linux, v.4.20.8-200.fc29.x86_64, x86_64 / gtk 3.24.1, WebKit 2.22.6
> Java version: 11.0.2
> 
> Reading a bit into the `org.eclipse.jdt` source code, I wonder if the
> problem may be that the shortReadableName computation does:
> 
> nameBuffer.append(this.type.sourceName);
> 
> Not all types have a name -- an anonymous class for example -- and the
> StringBuffer.append(char[]) is *not* null-safe:

If an anonymous class is part of the problem, then perhaps you can identify the section of your code that triggers the bug? 

Note: to create a parameterized type from an anonymous type, the *enclosing* type must be generic (since anonymous types cannot be generic). Then the anonymous is parameterized via its parameterized enclosing type.

With this in mind I could indeed trigger an error message that reads:
  "The method test(Number) in the type  is not applicable for the arguments (Object)"

Note the missing type name, caused by a LocalTypeBinding having an *empty* sourceName, not null. So, I'm not sure if an anonymous type is really the culprit.



Given that the exception happens during error reporting, don't you see a compile error in your project that would lead us to the code section in question?

The stack trace gives additional hints what code to look for, s.t. like

 m0() {
   try {
     m1(m2(..)); // m2() has a type checking problem, m1() likely is generic
   } finally { // or catch
   }
 }

Comment 4 Alex Foster 2019-02-19 18:56:12 EST

I think I made the error stop happening by updating my Java version to 11 somewhere, but I can't remember where exactly. It might have been under project > properties > build path or compiler or project facets.

Comment 5 Steven Schlansker 2019-02-21 12:30:18 EST

Yeah, anonymous type may have been too much speculation.  I did not have any compile errors at the time.  The error comes and goes, I managed to clear it by deleting the projects from Eclipse and removing .project, .classpath and redoing Maven import.

I'd thought it might be related to an error I have in a unrelated and closed project that's been a long-standing annoyance: https://github.com/jdbi/jdbi/pull/1472
but after switching the linked fix in and out, I decided that that wasn't the trigger either; the errors happened seemingly at random.

So unfortunately I am quite puzzled as to how to reproduce this.  It seems to be some combination of modulepath, classpath, open projects, and compile errors.

Given that this is itself happening in an error path (`ProblemReporter.typeMismatchError` and the ReferenceBinding we are attempting to pretty-print warns:

> Not all fields defined by this type (& its subclasses) are initialized when it is created.
> Some are initialized only when needed.

perhaps the bare field read and passing it into a null-unsafe append() is a bit too optimistic, and making the code slightly more null-defensive here will at least allow the error to be constructed and the next problem to be reported.

Comment 6 Stephan Herrmann 2019-02-21 14:35:42 EST

(In reply to Steven Schlansker from comment #5)
> Given that this is itself happening in an error path
> (`ProblemReporter.typeMismatchError` and the ReferenceBinding we are
> attempting to pretty-print warns:
> 
> > Not all fields defined by this type (& its subclasses) are initialized when it is created.
> > Some are initialized only when needed.
> 
> perhaps the bare field read and passing it into a null-unsafe append() is a
> bit too optimistic, and making the code slightly more null-defensive here
> will at least allow the error to be constructed and the next problem to be
> reported.

That explanation concerns information generated during resolving. ReferenceBinding#sourceName is not part of that group of fields.
It should be initialized in all constructors in the ReferenceBinding hierarchy.
I scanned call paths into relevant constructors and could not find any client with obvious risk of passing null.
Some suspects:
- Scope.createTypeVariables(TypeParameter[], Binding) takes the name from TypeParameter#name. There's a theoretical risk that the parser could leave this field at null - assuming some syntax error beforehand.
- BinaryTypeBinding.createTypeVariables(SignatureWrapper, boolean, char[][][], ITypeAnnotationWalker, boolean) creates the name as CharOperation.subarray(typeSignature, i, colon), which could theoretically be null in a corrupted class file.

Ergo: the design is clear to assume that ReferenceBinding#sourceName is never null. It would be a shame to dismiss this design and request that all 191 usage sites protect access with a null check. For lack of a better strategy we could protect the two suspect locations against creating a ReferenceBinding with a null #sourceName in the first place.

Comment 7 Dani Megert 2019-03-25 07:35:31 EDT

*** Bug 545724 has been marked as a duplicate of this bug. ***

Comment 8 Stephan Herrmann 2019-03-25 13:41:14 EDT

(In reply to Dani Megert from comment #7)
> *** Bug 545724 has been marked as a duplicate of this bug. ***

Interestingly, that bug additionally has this guy (which we've seen before, too):

java.lang.NullPointerException
	at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.getMemberType(ParameterizedTypeBinding.java:797)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:584)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:606)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:439)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:512)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:2006)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1336)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1377)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1519)
	at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:112)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:250)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:595)
	at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:670)
	at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:178)
	at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:95)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Not sure if there's a connection.

Comment 9 Jovan Radulovic 2019-03-26 04:22:49 EDT

https://bugs.eclipse.org/bugs/show_bug.cgi?id=545724
was marked as a duplicate though I see this bug was opened on 2018-11-03, and I haven't seen the NPE reference search bug on 2018-12 IDE.

Comment 10 Till Brychcy 2019-04-17 02:48:00 EDT

(In reply to Stephan Herrmann from comment #6)
> That explanation concerns information generated during resolving.
> ReferenceBinding#sourceName is not part of that group of fields.
> It should be initialized in all constructors in the ReferenceBinding
> hierarchy.

org.eclipse.jdt.internal.compiler.lookup.ProblemReferenceBinding.ProblemReferenceBinding(char[][], ReferenceBinding, int) doesn't set it.

Comment 11 Stephan Herrmann 2019-04-17 07:03:02 EDT

(In reply to Till Brychcy from comment #10)
> (In reply to Stephan Herrmann from comment #6)
> > That explanation concerns information generated during resolving.
> > ReferenceBinding#sourceName is not part of that group of fields.
> > It should be initialized in all constructors in the ReferenceBinding
> > hierarchy.
> 
> org.eclipse.jdt.internal.compiler.lookup.ProblemReferenceBinding.
> ProblemReferenceBinding(char[][], ReferenceBinding, int) doesn't set it.

Thanks for catching this. Perhaps that constructor can just synthesize a pseudo sourceName?

Comment 12 Paul Pazderski 2019-07-11 13:45:40 EDT

*** Bug 549188 has been marked as a duplicate of this bug. ***

Comment 13 Grzegorz Abramczyk 2019-07-29 14:25:13 EDT

I'm also affected by this bug. I'm trying to track the source and this is what I found out.

It looks like the ProblemReferenceBinding that causes trouble in shortReadableName method is constructed to report ambiguity between `java.util.Map<K extends java.lang.Object, V extends java.lang.Object>` and itself - but one entry have `module java.logging` and other `module java.base` so it looks like it is somehow related to the module system and a way that eclipse compiler handles it. I will try to prepare minimal example.

Comment 14 Andrey Loskutov 2019-07-29 14:27:00 EDT

(In reply to Grzegorz Abramczyk from comment #13)
> I'm also affected by this bug. I'm trying to track the source and this is
> what I found out.

Coukd you please try latest 4.13 nightly SDK build?

Comment 15 Grzegorz Abramczyk 2019-07-29 14:59:53 EDT

Created attachment 279426 [details]
Sample project demonstrating error

I managed to reproduce the error - and it looks like it surfaces when using java 11 (in my case: openjdk version "11.0.2" 2019-01-15/OpenJDK Runtime Environment 18.9 (build 11.0.2+9)/OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) and setting execution environment to java 10 level.

Comment 16 Grzegorz Abramczyk 2019-07-29 16:34:39 EDT

(In reply to Andrey Loskutov from comment #14)
> Coukd you please try latest 4.13 nightly SDK build?

On 

Version: 2019-09 (4.13)
Build id: I20190728-1800

and with my sample project the error still persists.

Comment 17 Stephan Herrmann 2019-07-29 18:44:09 EDT

(In reply to Grzegorz Abramczyk from comment #16)
> (In reply to Andrey Loskutov from comment #14)
> > Coukd you please try latest 4.13 nightly SDK build?
> 
> On 
> 
> Version: 2019-09 (4.13)
> Build id: I20190728-1800
> 
> and with my sample project the error still persists.

Thanks, I can reproduce. Failure is, however slightly different from the original exceptions reported here.

I filed bug 549646 for this specific NPE.

Then I investigated the ambiguous type issue in bug 549647, concluding that this is caused by a bug/insufficiency in JRE 11. Please make sure that --release 10 is used with either JRE 10 or JRE 12 but *not* with JRE 11 (see bug 549647 for a few more details).

Comment 18 Eclipse Genie 2022-06-03 12:25:12 EDT

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.

Comment 19 Simeon Andreev 2023-03-14 05:33:25 EDT

Not seen when running Eclipse 4.27 on Java 17, and using the attached example (that has a JRE 10 container on its classpath).

Please re-open if you have a new reproducer with more recent Eclipse and JRE (Eclipse requires Java 17 now).