Comment 1 Stephan Herrmann 2015-08-01 05:35:10 EDT

Probably similar to bug 470232?

Normally, we'd really need to figure out, why a null happened in the first place, but during LambdaExpression.isCompatibleWith() it's *probably* OK to expect missing bindings. I wonder if a few methods like this should actually *catch* NPE, rather than cluttering methods which never before saw nulls with null checks that have an empty else ... 

Looking at this frame:
    at org.eclipse.jdt.internal.compiler.lookup.Scope.computeCompatibleMethod(Scope.java:768)

we're probably about to report an error anyway.

Comment 2 Sasikanth Bharadwaj 2016-04-22 02:18:48 EDT

Moving out, hadn't looked at it

Comment 3 Jay Arthanareeswaran 2016-10-19 09:59:57 EDT

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

Comment 4 Sasikanth Bharadwaj 2017-05-15 05:09:12 EDT

Moving out of 4.7

Comment 5 Manoj N Palat 2018-08-16 00:30:13 EDT

Bulk move out of 4.9

Comment 6 Stephen Crowley 2020-01-14 16:06:22 EST

This problem makes some things unclickable by holding ctrl and clicking

!ENTRY org.eclipse.jface.text 4 0 2020-01-14 15:01:06.281
!MESSAGE Unexpected runtime error while computing a text hover
!STACK 0
java.lang.NullPointerException
	at org.eclipse.jdt.internal.compiler.ast.QualifiedNameReference.optimizedBooleanConstant(QualifiedNameReference.java:931)
	at org.eclipse.jdt.internal.compiler.ast.WhileStatement.doesNotCompleteNormally(WhileStatement.java:309)
	at org.eclipse.jdt.internal.compiler.ast.Block.doesNotCompleteNormally(Block.java:168)
	at org.eclipse.jdt.internal.compiler.ast.LambdaExpression.resolveType(LambdaExpression.java:463)
	at org.eclipse.jdt.internal.compiler.ast.LambdaExpression.cachedResolvedCopy(LambdaExpression.java:974)
	at org.eclipse.jdt.internal.compiler.ast.LambdaExpression.internalIsCompatibleWith(LambdaExpression.java:889)
	at org.eclipse.jdt.internal.compiler.ast.LambdaExpression.isCompatibleWith(LambdaExpression.java:880)
	at org.eclipse.jdt.internal.compiler.lookup.PolyTypeBinding.isCompatibleWith(PolyTypeBinding.java:43)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.parameterCompatibilityLevel(Scope.java:4957)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.parameterCompatibilityLevel(Scope.java:4921)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.computeCompatibleMethod(Scope.java:867)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.computeCompatibleMethod(Scope.java:794)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getConstructor0(Scope.java:2474)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getConstructor(Scope.java:2437)
	at org.eclipse.jdt.internal.compiler.ast.Statement.findConstructorBinding(Statement.java:504)
	at org.eclipse.jdt.internal.compiler.ast.AllocationExpression.resolveType(AllocationExpression.java:491)
	at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:691)
	at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:1066)
	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:1293)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1418)
	at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:666)
	at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:875)
	at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:672)
	at org.eclipse.jdt.internal.core.hierarchy.HierarchyBuilder.buildSupertypes(HierarchyBuilder.java:129)
	at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:170)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:323)
	at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1319)
	at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:94)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:736)
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:802)
	at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:795)
	at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:746)
	at org.eclipse.jdt.internal.corext.util.SuperTypeHierarchyCache.getTypeHierarchy(SuperTypeHierarchyCache.java:144)
	at org.eclipse.jdt.internal.corext.util.SuperTypeHierarchyCache.getTypeHierarchy(SuperTypeHierarchyCache.java:96)
	at org.eclipse.jdt.internal.ui.text.javadoc.JavadocContentAccess2$JavadocLookup.getTypeHierarchy(JavadocContentAccess2.java:464)
	at org.eclipse.jdt.internal.ui.text.javadoc.JavadocContentAccess2$JavadocLookup.getInheritedDescription(JavadocContentAccess2.java:418)
	at org.eclipse.jdt.internal.ui.text.javadoc.JavadocContentAccess2$JavadocLookup.getInheritedMainDescription(JavadocContentAccess2.java:312)
	at org.eclipse.jdt.internal.ui.text.javadoc.JavadocContentAccess2.elementToHTML(JavadocContentAccess2.java:1049)
	at org.eclipse.jdt.internal.ui.text.javadoc.JavadocContentAccess2.toHTML(JavadocContentAccess2.java:870)
	at org.eclipse.jdt.internal.ui.text.javadoc.JavadocContentAccess2.javadoc2HTML(JavadocContentAccess2.java:788)
	at org.eclipse.jdt.internal.ui.text.javadoc.JavadocContentAccess2.getHTMLContentFromSource(JavadocContentAccess2.java:666)
	at org.eclipse.jdt.internal.ui.text.javadoc.JavadocContentAccess2.getHTMLContent(JavadocContentAccess2.java:538)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getHoverInfo(JavadocHover.java:760)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.internalGetHoverInfo(JavadocHover.java:678)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavadocHover.getHoverInfo2(JavadocHover.java:670)
	at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:165)
	at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:132)
	at org.eclipse.jdt.internal.ui.text.java.hover.JavaEditorTextHoverProxy.getHoverInfo2(JavaEditorTextHoverProxy.java:89)
	at org.eclipse.jface.text.TextViewerHoverManager$4.run(TextViewerHoverManager.java:169)

Comment 7 Stephan Herrmann 2020-01-14 16:32:14 EST

(In reply to Stephen Crowley from comment #6)
> This problem makes some things unclickable by holding ctrl and clicking

You could tremendously help us by providing a reproducing project.

Comment 8 Stephen Crowley 2020-01-14 17:33:20 EST

Is there any other way I could help? I can't share the project code publicly. How do I checkout the source to the module throwing the NPE (which is the JDT package) and build it and plug it into my current eclipse instance?

Comment 9 Stephan Herrmann 2020-01-14 18:12:11 EST

(In reply to Stephen Crowley from comment #8)
> Is there any other way I could help? I can't share the project code
> publicly. How do I checkout the source to the module throwing the NPE (which
> is the JDT package) and build it and plug it into my current eclipse
> instance?

Thanks for the offer. Please have a look at https://wiki.eclipse.org/JDT_Code_Setup_Using_Oomph

This will give you a JDT development environment (Eclipse installation & workspace). We are mainly interested in only one project: org.eclipse.jdt.core aka JDT/Core.

Then in your main Eclipse, edit eclipse.ini to enable remote debugging, s.t. like

-vmargs
-agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n

-vmargs must be the last section in eclipse.ini.
Launch this Eclipse...

... then in the JDT environment run a new debug session as Remote Java Application, see https://help.eclipse.org/2019-12/topic/org.eclipse.jdt.doc.user/tasks/task-remotejava_launch_config.htm

Comment 10 Stephen Crowley 2020-01-16 18:48:59 EST

I managed to fix it by checking for the NPE

diff --git a/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/QualifiedNameReference.java b/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/QualifiedNameReference.java
index cec0657..8ef4bc3 100644
--- a/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/QualifiedNameReference.java
+++ b/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/QualifiedNameReference.java
@@ -928,6 +928,9 @@
 
 @Override
 public Constant optimizedBooleanConstant() {
+	if ( this.resolvedType == null ) {
+		return Constant.NotAConstant;
+	}
 	switch (this.resolvedType.id) {
 		case T_boolean :
 		case T_JavaLangBoolean :

Comment 11 Stephan Herrmann 2020-01-17 10:46:05 EST

(In reply to Stephen Crowley from comment #10)
> I managed to fix it by checking for the NPE
> 
> diff --git
> a/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/
> QualifiedNameReference.java
> b/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/
> QualifiedNameReference.java
> index cec0657..8ef4bc3 100644
> ---
> a/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/
> QualifiedNameReference.java
> +++
> b/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/
> QualifiedNameReference.java
> @@ -928,6 +928,9 @@
>  
>  @Override
>  public Constant optimizedBooleanConstant() {
> +	if ( this.resolvedType == null ) {
> +		return Constant.NotAConstant;
> +	}
>  	switch (this.resolvedType.id) {
>  		case T_boolean :
>  		case T_JavaLangBoolean :

Congrats, so you seem to have your dev-env up and running, and found the location. A simply null check is, however, in many cases not the solution but just some band-aid for this particular use case.

So, I would be interested to learn about the elements that are currently being compiled. Can you guess any reason, why that qualified name doesn't have a resolved type?

Normally, such null would signal a bug elsewhere in the compiler, but here we seem to be in the situation that speculative analysis of a lambda (before its type is known) provides a suitable "excuse" for abnormal situation.

Would you now be in a position to create a reproducing example, by reconstructing the same program structure that you see in the debugger in a demo project? If so, I would love to play with it to see if I can find a safer solution.

Comment 12 Stephen Crowley 2020-01-17 17:20:45 EST

Created attachment 281535 [details]
something to do with  this.body.doesNotCompleteNormally() on a Lambda expression?

I think it has something to do with 

 this.body.doesNotCompleteNormally();


I added a "return;" to the end of the lambda expression triggering the NPE and now the exception does not occur... 

--- Method Scope ---
	locals:
	startIndex = 0
	isConstructorCall = false
	initializedField = null
	lastVisibleFieldID = -1
	referenceContext = public @Override void start() {
  new Thread(() -> {
  while (eventSequence.running)    {
      try
        {
          double t = config.getTime(tick());
          if ((t >= MarketMaker.closeTime))
              {
                if ((! stopped))
                    {
                      try
                        {
                          System.out.println("Stopping...");
                          doStuff();
                          Thread.sleep(250);
                          System.out.println("Simulation finished");
                        }
                      catch (InterruptedException e)
                        {
                          e.printStackTrace();
                        }
                      mainFrame.simulator.stop();
                      stopped = true;
                    }
              }
        }
      catch (IOException e)
        {
          e.printStackTrace();
        }
    }
}).start();
}

Comment 13 Stephen Crowley 2020-01-17 17:24:38 EST

I meant to say , putting "return;" after the end of the while statement inside the lambda expression, and before the end of the lambda expression, seems to have cured it

Comment 14 Stephan Herrmann 2020-01-17 17:33:57 EST

(In reply to Stephen Crowley from comment #12)
> 
> --- Method Scope ---
> 	locals:
> 	startIndex = 0
> 	isConstructorCall = false
> 	initializedField = null
> 	lastVisibleFieldID = -1
> 	referenceContext = public @Override void start() {
>   new Thread(() -> {
>   while (eventSequence.running)    {
>       try
>         {
>           double t = config.getTime(tick());
>           if ((t >= MarketMaker.closeTime))
>               {
>                 if ((! stopped))
>                     {
>                       try
>                         {
>                           System.out.println("Stopping...");
>                           doStuff();
>                           Thread.sleep(250);
>                           System.out.println("Simulation finished");
>                         }
>                       catch (InterruptedException e)
>                         {
>                           e.printStackTrace();
>                         }
>                       mainFrame.simulator.stop();
>                       stopped = true;
>                     }
>               }
>         }
>       catch (IOException e)
>         {
>           e.printStackTrace();
>         }
>     }
> }).start();
> }

Bingo, this method suffices to reproduce the NPE. From here I can start looking for the best possible fix.

Comment 15 Stephan Herrmann 2020-02-28 18:23:54 EST

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

Comment 16 Stephan Herrmann 2020-02-28 18:24:23 EST

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

Comment 17 Eclipse Genie 2020-05-24 09:32:12 EDT

New Gerrit change created: https://git.eclipse.org/r/163483

Comment 18 Stephan Herrmann 2020-05-24 09:52:19 EDT

(In reply to Eclipse Genie from comment #17)
> New Gerrit change created: https://git.eclipse.org/r/163483

As usual I'm reluctant to mechanically adding null checks. In this case the unexpected null can be explained as follows:

In my reduced version of the example, the reference eventSequence.running is unresolved, i.e., QualifiedNameReference.resolvedType is null indeed. While resolve errors will set ignoreFurtherInvestigation to true preventing NPE in downstream compilation phases, this doesn't help for cases like this, where the null deference happens in the same phase.

To codify this analysis I'm not checking resolvedType != null, but binding.isValidBinding(). Theoretically, also binding could be null, but that would have a different cause and hence that's something I still want to escalate, should it ever happen.

(In reply to Stephen Crowley from comment #13)
> I meant to say , putting "return;" after the end of the while statement
> inside the lambda expression, and before the end of the lambda expression,
> seems to have cured it

yes, this works around the issue, because with that return as the last statement in the block, we don't need to ask WhileStatement.doesNotCompleteNormally().

Still, I obviously don't know what exactly caused resolvedType to be null in the original example. 

@Stephen, once you added the 'return;' did you see any compile errors in this method? Which?

Anyway the fix is simple and effective, hence proposing for RC1.

Comment 19 Jay Arthanareeswaran 2020-05-25 00:21:25 EDT

Looked at the patch and looks good to me. 

+1 for RC1.

Comment 20 Eclipse Genie 2020-05-25 03:57:40 EDT

Gerrit change https://git.eclipse.org/r/163483 was merged to [master].
Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=b6f11a1732f11ce5a45b023441a4b452ef46f84f

Comment 21 Stephan Herrmann 2020-05-25 03:59:04 EDT

(In reply to Jay Arthanareeswaran from comment #19)
> Looked at the patch and looks good to me. 
> 
> +1 for RC1.

thanks

(In reply to Eclipse Genie from comment #20)
> Gerrit change https://git.eclipse.org/r/163483 was merged to [master].
> Commit:
> http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/
> ?id=b6f11a1732f11ce5a45b023441a4b452ef46f84f

released to master for 4.16 RC1

Comment 22 Jay Arthanareeswaran 2020-05-28 05:00:51 EDT

Verified for 4.16 RC1 using build I20200524-1800.

Comment 23 Jay Arthanareeswaran 2020-05-28 05:05:14 EDT

(In reply to Jay Arthanareeswaran from comment #22)
> Verified for 4.16 RC1 using build I20200524-1800.

Meant I20200527-1800.

Comment 24 Pierre-Yves Bigourdan 2020-06-02 10:24:34 EDT

I bumped into this issue as well (JDT from 2020-04-27). It looks like an example to reproduce was found in the end, but I'll add mine here just for reference.

pom.xml:
<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>test</groupId>
    <artifactId>test-npe</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <properties>
        <java.version>11</java.version>
        <maven.compiler.source>${java.version}</maven.compiler.source>
        <maven.compiler.target>${java.version}</maven.compiler.target>
    </properties>
    <dependencies>
        <dependency>
            <artifactId>reactor-netty</artifactId>
            <groupId>io.projectreactor.netty</groupId>
            <version>0.9.7.RELEASE</version>
        </dependency>
    </dependencies>
</project>


Main.java:
import java.util.Iterator;
import java.util.Map.Entry;

import io.netty.channel.ChannelHandler;
import io.netty.handler.ssl.SslMasterKeyHandler;
import reactor.netty.channel.BootstrapHandlers;
import reactor.netty.tcp.TcpClient;

public class Main {
    public static void main(String[] args) {
        TcpClient tcpClient = TcpClient.create()
                .doOnConnect(b -> {
                    BootstrapHandlers.updateConfiguration(b, "test", (co, ch) -> {
                        Iterator<Entry<String, ChannelHandler>> iterator = ch.pipeline().iterator();
                        while (iterator.) {
                        }
                    });
                });
    }
}

The NPE will happen by triggering autocomplete after "iterator.".

Comment 25 Stephan Herrmann 2020-06-02 14:29:30 EDT

(In reply to Pierre-Yves B. from comment #24)
> I bumped into this issue as well (JDT from 2020-04-27). It looks like an
> example to reproduce was found in the end,

Indeed, see https://git.eclipse.org/r/#/c/163483/1/org.eclipse.jdt.core.tests.compiler/src/org/eclipse/jdt/core/tests/compiler/regression/FlowAnalysisTest8.java

> but I'll add mine here just for reference.
> [...]
> The NPE will happen by triggering autocomplete after "iterator.".

Thanks, does the NPE still occur with recent builds?

Comment 26 Pierre-Yves Bigourdan 2020-06-03 03:41:54 EDT

(In reply to Stephan Herrmann from comment #25)
> Thanks, does the NPE still occur with recent builds?

For some reason I haven't received any new builds for a while. The JDT version I have installed is 3.18.450.v20200427-1819, but on the nightly update site (https://download.eclipse.org/eclipse/updates/4.16-I-builds/) I can see that 3.18.400.v20200602-1800 is the latest. It seems that the version was mistakenly bumped to 3.18.450 at some point than brought back to 3.18.400 later on, Eclipse therefore thinks I'm still on most recent.

I tried uninstalling JDT to reinstall it, unfortunately, that fails, Eclipse claims that other products within the IDE depend on it.

Unless you have a magical trick to sort things out, seems like I won't be able to beta test anything new and am forced to stick with older 3.18.450.v20200427-1819 until the version is bumped again.

Comment 27 Stephan Herrmann 2020-06-03 14:38:47 EDT

(In reply to Pierre-Yves B. from comment #26)
> (In reply to Stephan Herrmann from comment #25)
> > Thanks, does the NPE still occur with recent builds?
> 
> For some reason I haven't received any new builds for a while. The JDT
> version I have installed is 3.18.450.v20200427-1819, but on the nightly
> update site (https://download.eclipse.org/eclipse/updates/4.16-I-builds/) I
> can see that 3.18.400.v20200602-1800 is the latest. It seems that the
> version was mistakenly bumped to 3.18.450 at some point than brought back to
> 3.18.400 later on, Eclipse therefore thinks I'm still on most recent.
> 
> I tried uninstalling JDT to reinstall it, unfortunately, that fails, Eclipse
> claims that other products within the IDE depend on it.
> 
> Unless you have a magical trick to sort things out, seems like I won't be
> able to beta test anything new and am forced to stick with older
> 3.18.450.v20200427-1819 until the version is bumped again.

Outch, this is unfortunate. I can see that on 2020-04-27 the JDT feature [1] was accidentally bumped up to 3.18.450 (this was intended for the BETA_JAVA15 branch). Right the next day, this change was reverted. Apparently, you were 'lucky' to update on the single buggy day.

Still, there should be different ways to get you out of that ditch. :)

Firstly, have you tried explicitly installing Eclipse SDK from  the I-builds repo you mention? P2 should recognize this as a downgrade, but perhaps after waiting for the remediation process (where it counts alternative attempts 1 through 15) it should give you "downgrading" to the selected version as an option.

Next, and only if the previous does not work, got to About > Installation Details > Installation History. Select a date prior to 2020-04-27 and click Revert. I'm not sure if you need to restart at that point. One way or other it should put you into a position where normal updating works again.

Last, if all fails, get yourself a new Eclipse installation, it's for free :)

[1] https://git.eclipse.org/c/jdt/eclipse.jdt.git/tree/org.eclipse.jdt-feature/feature.xml

Comment 28 Pierre-Yves Bigourdan 2020-06-04 05:08:48 EDT

(In reply to Stephan Herrmann from comment #27
> Still, there should be different ways to get you out of that ditch. :)
> 
> Firstly, have you tried explicitly installing Eclipse SDK from  the I-builds
> repo you mention? P2 should recognize this as a downgrade, but perhaps after
> waiting for the remediation process (where it counts alternative attempts 1
> through 15) it should give you "downgrading" to the selected version as an
> option.

Unfortunately this does not seem to work. When I select "Eclipse SDK", P2 suggests installing it but removing all of "Eclipse IDE for Java Developers", "Eclipse Java Development Tools", "Eclipse Platform" and "Eclipse RCP". Trying to progress any further fails with conflicts anyway.


> Next, and only if the previous does not work, got to About > Installation
> Details > Installation History. Select a date prior to 2020-04-27 and click
> Revert. I'm not sure if you need to restart at that point. One way or other
> it should put you into a position where normal updating works again.

This did work, thanks! I occasionally use this revert installation feature but did not realise it kept entries from several months ago. I could literally go back to my IDE back in mid-2019 if I wanted to!


My turn to be "useful": I've now installed the latest JDT now (Eclipse Java Development Tools 3.18.400.v20200603-0600), but unfortunately I'm still seeing the same error with the example I shared previously:
java.lang.NullPointerException
	at org.eclipse.jdt.internal.compiler.ast.QualifiedNameReference.optimizedBooleanConstant(QualifiedNameReference.java:931)
	at org.eclipse.jdt.internal.compiler.ast.WhileStatement.doesNotCompleteNormally(WhileStatement.java:313)
	at org.eclipse.jdt.internal.compiler.ast.Block.doesNotCompleteNormally(Block.java:174)
	at org.eclipse.jdt.internal.compiler.ast.LambdaExpression.analyzeShape(LambdaExpression.java:839)
	at org.eclipse.jdt.internal.compiler.ast.LambdaExpression.isPotentiallyCompatibleWith(LambdaExpression.java:862)
	at org.eclipse.jdt.internal.compiler.lookup.PolyTypeBinding.isPotentiallyCompatibleWith(PolyTypeBinding.java:48)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.parameterCompatibilityLevel(Scope.java:5066)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.parameterCompatibilityLevel(Scope.java:5032)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.computeCompatibleMethod(Scope.java:871)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.computeCompatibleMethod(Scope.java:798)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod0(Scope.java:1756)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1657)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:3046)
	at org.eclipse.jdt.internal.compiler.ast.MessageSend.findMethodBinding(MessageSend.java:1017)
	at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:838)
	at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:1082)
	at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:131)
	at org.eclipse.jdt.internal.compiler.ast.LambdaExpression.resolveType(LambdaExpression.java:458)
	at org.eclipse.jdt.internal.compiler.ast.ASTNode.resolvePolyExpressionArguments(ASTNode.java:718)
	at org.eclipse.jdt.internal.compiler.ast.MessageSend.findMethodBinding(MessageSend.java:1024)
	at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:838)
	at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:409)
	at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:270)
	at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:660)
	at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:361)
	at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:569)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1490)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1615)
	at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:667)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.complete(CompletionEngine.java:2280)
	at org.eclipse.jdt.internal.core.Openable.codeComplete(Openable.java:136)
	at org.eclipse.jdt.internal.core.CompilationUnit.codeComplete(CompilationUnit.java:366)
	at org.eclipse.jdt.internal.core.CompilationUnit.codeComplete(CompilationUnit.java:356)
	at org.eclipse.jdt.internal.ui.text.java.JavaCompletionProposalComputer.internalComputeCompletionProposals(JavaCompletionProposalComputer.java:257)
	at org.eclipse.jdt.internal.ui.text.java.JavaCompletionProposalComputer.computeCompletionProposals(JavaCompletionProposalComputer.java:219)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:345)
	at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:340)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:333)
	at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:289)
	at org.eclipse.jface.text.contentassist.AsyncCompletionProposalPopup.lambda$10(AsyncCompletionProposalPopup.java:351)
	at org.eclipse.jface.text.contentassist.AsyncCompletionProposalPopup$$Lambda$993/00000000D3371A20.run(Unknown Source)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.jface.text.contentassist.AsyncCompletionProposalPopup.lambda$9(AsyncCompletionProposalPopup.java:350)
	at org.eclipse.jface.text.contentassist.AsyncCompletionProposalPopup$$Lambda$991/00000000D4B14A20.get(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1764)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1756)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)