Starting from version 1.36.0 it is not possible to use the Quick fix Add constructor in classes that use inheritance

[ramonnascimento-montreal]

Starting from version 1.36.0 it is not possible to use the Quick fix Add constructor in classes that use inheritance.

I tried following the Troubleshooting guide recommendations and also manually cleaning the workspaceStorage directory. Even reinstalling vscode among other alternatives, the only one that worked was installing the vscode extension from version 1.35.1 downwards.

Sample class

Language Support for Java log

dez. 26, 2024 12:53:02 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint fallbackResponseError
GRAVE: Internal error: org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
java.util.concurrent.CompletionException: org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
Caused by: org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:119)
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:104)
	at org.eclipse.jface.text.Position.<init>(Position.java:65)
	at org.eclipse.jface.text.link.LinkedPosition.<init>(LinkedPosition.java:46)
	at org.eclipse.jdt.ls.core.internal.contentassist.SnippetUtils.addSnippetsIfApplicable(SnippetUtils.java:134)
	at org.eclipse.jdt.ls.core.internal.handlers.CodeActionResolveHandler.resolve(CodeActionResolveHandler.java:54)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$15(JDTLanguageServer.java:786)
	at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)
	... 7 more

Developer tools log

  ERR Internal error.: Error: Internal error.
	at c:\Users\ramon.nascimento\.vscode\extensions\redhat.java-1.36.0-win32-x64\dist\extension.js:2:1072098
	at re (c:\Users\ramon.nascimento\.vscode\extensions\redhat.java-1.36.0-win32-x64\dist\extension.js:2:1072392)
	at c:\Users\ramon.nascimento\.vscode\extensions\redhat.java-1.36.0-win32-x64\dist\extension.js:2:1067176
	at Immediate.<anonymous> (c:\Users\ramon.nascimento\.vscode\extensions\redhat.java-1.36.0-win32-x64\dist\extension.js:2:1067196)
	at process.processImmediate (node:internal/timers:483:21)

Other details

The project is a simple class but I'm uploading it:

AddConstructor.zip

Environment

Operating System: Windows 10 Pro x64
JDK version: Eclipse Adoptium JDK 8 / 17 (both can reproduce the problem)
Visual Studio Code version: 1.96.2
Language Support for Java(TM) by Red Hat version: 1.38.0 to 1.36.0

Video demonstration

1.36.0 version (not working): https://vimeo.com/1042281037/c6bad7911b
1.35.1 version (working): https://vimeo.com/1042284085/46e808f05a

[rhystedstone]

I've also been having this exact issue for a while with Eclipse Adoptium JDK 1.8, 11 and 21. I can also confirm that reverting to v1.35.x does work.

Operating System: Windows 11 Pro 24H2 (26100.2605)
JDK version: Eclipse Adoptium JDK 1.8, 11 & 21
Visual Studio Code version: 1.96.2
Language Support for Java(TM) by Red Hat version: 1.38.0

[rgrunber]

[Error - 10:13:57] Request codeAction/resolve failed.
  Message: Internal error.
  Code: -32603 
java.util.concurrent.CompletionException: org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
	at java.base/java.util.concurrent.CompletableFuture.wrapInCompletionException(CompletableFuture.java:323)
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:359)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:364)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:693)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:527)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1458)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2034)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:189)
Caused by: org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:119)
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:104)
	at org.eclipse.jface.text.Position.<init>(Position.java:65)
	at org.eclipse.jface.text.link.LinkedPosition.<init>(LinkedPosition.java:46)
	at org.eclipse.jdt.ls.core.internal.contentassist.SnippetUtils.addSnippetsIfApplicable(SnippetUtils.java:134)
	at org.eclipse.jdt.ls.core.internal.handlers.CodeActionResolveHandler.resolve(CodeActionResolveHandler.java:54)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$15(JDTLanguageServer.java:787)
	at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:690)
	... 5 more

Thanks for filing this. I'm able to reproduce even on Linux.

Looks like it's a bug from a new feature, #3780 . It's happening somewhere on https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/c61609814aa34e7ddab34afa282cba18bf56f933/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/contentassist/SnippetUtils.java#L109 . Specifically, positionList[i].getOffset() appears to not be greater than 0 (based on the assert from the stacktrace). Looking at its javadocs that value can be -1 so maybe we're not handling that case correctly.

Update: I have a fix for this that just works around the issue. It ends up being as good as upstream JDT's generated code action. Just some notes for myself (and possibly others) regarding the -1. The purpose of Add construtor "AType(String)" is to create something like :

public Atype(String name) {
	super(name);
}

In this case, the JDT api offers the ability to directly link the parameter declaration to the super invocation, so that if the user opts to change "name", it will be updated in both positions dynamically. The problem is that entire constructor has no offsets in the model because it hasn't been applied yet (I think). So the offset ends up being -1. I think this is just a limitation upstream in how they implemented this.

[ramonnascimento-montreal]

[Error - 10:13:57] Request codeAction/resolve failed.
  Message: Internal error.
  Code: -32603 
java.util.concurrent.CompletionException: org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
	at java.base/java.util.concurrent.CompletableFuture.wrapInCompletionException(CompletableFuture.java:323)
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:359)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:364)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:693)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:527)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1458)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2034)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:189)
Caused by: org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:119)
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:104)
	at org.eclipse.jface.text.Position.<init>(Position.java:65)
	at org.eclipse.jface.text.link.LinkedPosition.<init>(LinkedPosition.java:46)
	at org.eclipse.jdt.ls.core.internal.contentassist.SnippetUtils.addSnippetsIfApplicable(SnippetUtils.java:134)
	at org.eclipse.jdt.ls.core.internal.handlers.CodeActionResolveHandler.resolve(CodeActionResolveHandler.java:54)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$15(JDTLanguageServer.java:787)
	at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:690)
	... 5 more

Thanks for filing this. I'm able to reproduce even on Linux.

Looks like it's a bug from a new feature, #3780 . It's happening somewhere on https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/c61609814aa34e7ddab34afa282cba18bf56f933/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/contentassist/SnippetUtils.java#L109 . Specifically, positionList[i].getOffset() appears to not be greater than 0 (based on the assert from the stacktrace). Looking at its javadocs that value can be -1 so maybe we're not handling that case correctly.

Update: I have a fix for this that just works around the issue. It ends up being as good as upstream JDT's generated code action. Just some notes for myself (and possibly others) regarding the -1. The purpose of Add construtor "AType(String)" is to create something like :

public Atype(String name) {
	super(name);
}

In this case, the JDT api offers the ability to directly link the parameter declaration to the super invocation, so that if the user opts to change "name", it will be updated in both positions dynamically. The problem is that entire constructor has no offsets in the model because it hasn't been applied yet (I think). So the offset ends up being -1. I think this is just a limitation upstream in how they implemented this.

Thank you for such a quick response @rgrunber!