Update LSP4J to 0.24.0 and Xtend/Xtext to 2.32.0

[dasTanmoy0096]

Bump org.eclipse.lsp4j (0.13.0→0.24.0) and org.eclipse.xtend/xtext (2.24.0→2.32.0). Update external binaries, license files and project metadata; adapt small API changes (Preconditions import and prepareRename → Either3).

---

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[dasTanmoy0096]

Sorry for the repeated commits, first time trying to contribue to NetBeans trying to get a hang around

[mbien]

no worries. its an iterative process. Updating dependencies can be tricky in NB. Lets see what CI says.

I only took a quick look but 2.32.0 makes sense to me since it is what 0.24.0 would resolve to, e.g:

mvn eu.maveniverse.maven.plugins:toolbox:gav-tree -Dgav=org.eclipse.lsp4j:org.eclipse.lsp4j.generator:0.24.0
...
[INFO] --- toolbox:0.15.0:gav-tree (default-cli) @ standalone-pom ---
[INFO] org.eclipse.lsp4j:org.eclipse.lsp4j.generator:jar:0.24.0 (origin: central)
[INFO] ├─org.eclipse.lsp4j:org.eclipse.lsp4j.jsonrpc:jar:0.24.0 [compile] (origin: central)
[INFO] │ ╰─com.google.code.gson:gson:jar:2.13.2 [compile] (range '[2.9.1,3.0)') (origin: central)
[INFO] │   ╰─com.google.errorprone:error_prone_annotations:jar:2.41.0 [compile] (origin: central)
[INFO] ╰─org.eclipse.xtend:org.eclipse.xtend.lib:jar:2.32.0 [compile] (origin: central)
[INFO]   ├─org.eclipse.xtext:org.eclipse.xtext.xbase.lib:jar:2.32.0 [compile] (origin: central,sonatype-snapshots)
[INFO]   │ ╰─com.google.guava:guava:jar:32.1.2-jre [compile] (origin: central,sonatype-snapshots)
[INFO]   │   ├─com.google.guava:failureaccess:jar:1.0.1 [compile] (origin: central,sonatype-snapshots)
[INFO]   │   ├─com.google.guava:listenablefuture:jar:9999.0-empty-to-avoid-conflict-with-guava [compile] (origin: central,sonatype-snapshots)
[INFO]   │   ├─com.google.code.findbugs:jsr305:jar:3.0.2 [compile] (origin: central,sonatype-snapshots)
[INFO]   │   ├─org.checkerframework:checker-qual:jar:3.33.0 [compile] (origin: central,sonatype-snapshots)
[INFO]   │   ╰─com.google.j2objc:j2objc-annotations:jar:2.8 [compile] (origin: central,sonatype-snapshots)
[INFO]   ╰─org.eclipse.xtend:org.eclipse.xtend.lib.macro:jar:2.32.0 [compile] (origin: central,sonatype-snapshots)

Bytecode level seems to be JDK 11 which is fine too. The gson lib wrapper likely needs updating too (that would be a separate commit since it is an independent module).

regarding paperwork:

Feel free to squash everything (LSP related) to one commit and force push. The resulting commit must have a valid email address, you can verify it by looking at the generated patch https://github.com/apache/netbeans/pull/9098.patch.
Github has a setting somewhere to replace the mail with a noreply address which is probably the reason for it. But you can also update the commit locally which should work too.

Once reviewed, we would merge the branch as-is so the commit(s) should also have a descriptive message (e.g without intermediate status updates like "fixed license name" etc which might be left after squashing).

[dasTanmoy0096]

Thanks for the suggestions, did the following:-

1. Squashed all commits into a single one with a proper description
2. Changed my email from the no-reply email to the real one

What I did not do:-

1. Update gson lib; as the version that's being consumed by LSP/DAP is independent from the other versions and seems to be working fine; but I can try updating them (as well as other libaries) in a separate scope.
2. The failing LSP Tests. Regarding the following Assertion Errors:-

junit.framework.AssertionFailedError: expected:<1> but was:<2>
      [junit] 	at junit.framework.Assert.fail(Assert.java:57)
      [junit] 	at junit.framework.Assert.failNotEquals(Assert.java:329)
      [junit] 	at junit.framework.Assert.assertEquals(Assert.java:78)
      [junit] 	at junit.framework.Assert.assertEquals(Assert.java:234)
      [junit] 	at junit.framework.Assert.assertEquals(Assert.java:241)
      [junit] 	at junit.framework.TestCase.assertEquals(TestCase.java:384)
      [junit] 	at org.netbeans.modules.java.lsp.server.protocol.ServerTest$52.configuration(ServerTest.java:5917)

and

Testcase: testChangeMethodParameters(org.netbeans.modules.java.lsp.server.protocol.ServerTest):	FAILED
      [junit] expected:<2> but was:<1>
      [junit] junit.framework.AssertionFailedError: expected:<2> but was:<1>
      [junit] 	at org.netbeans.modules.java.lsp.server.protocol.ServerTest.testChangeMethodParameters(ServerTest.java:4739)
      [junit] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      [junit] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
      [junit] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      [junit] 	at org.netbeans.junit.NbTestCase.access$200(NbTestCase.java:84)
      [junit] 	at org.netbeans.junit.NbTestCase$2.doSomething(NbTestCase.java:489)
      [junit] 	at org.netbeans.junit.NbTestCase$1Guard.run(NbTestCase.java:410)
      [junit] 	at java.base/java.lang.Thread.run(Thread.java:840) 

Am not exactly sure what exactly are the issues as the entire IDE itself is building on my end and all the tests are passing without any errors. An answer from Copilot tells me the following:-

That failure is coming from the test’s LSP client stub in ServerTest.java:5916-5923: it intercepts every server→client workspace/configuration request and assumes the server will always ask for exactly one configuration key per request.

In CI, the server sometimes legitimately sends a ConfigurationParams with two ConfigurationItems, so your hard assertion assertEquals(1, configurationParams.getItems().size()) fails.

Why it can be 2 in CI but not locally (most likely)

The server has two different code paths that call client.configuration(new ConfigurationParams(items)):
“Normal” single-key fetch via ClientConfigurationManager.java:108-151 (your inlay-hints path: one key → one item).
“Refresh all scoped values after config change” via ConfigValueCache.java:80-115, which builds a list of ConfigurationItem for every remembered scope for that section and sends them in one request.
In your testInlayHints, you call didChangeConfiguration(...) multiple times after requesting hints. That triggers handleConfigurationChange(...) → ConfigValueCache.updateCache(...), which may request configuration for all scopes it has cached so far.
Whether the cache ends up with one scope or two can vary by environment/timing, because scope computation depends on project/workspace resolution inside ClientConfigurationManager.java:108-126 (it calls getProjectFromFileScope(scope)). If CI resolves the file to a “project URI” in one moment and to a “workspace folder URI” (or a different project identity) in another moment, you can end up with two distinct scope keys stored for the same config section. Then updateCache refreshes both at once → items.size() == 2.
So the test is brittle: it’s not only validating “the inlay hint key is requested”, it’s also (unintentionally) asserting “the server will never batch configuration requests / never refresh multiple scopes in one call”, which is not a stable guarantee.

A 'netbeans-vscode' repository using my changes to the 'netbeans' submodule is also building the extension just fine; and the 'ant test-lsp-server' and 'ant test-vscode-ext' tests pass without any errors.

[dasTanmoy0096]

Not sure if I can fix the Tests, but I can fix my email commit headers with a fresh PR, since for some reason it's still stuck on my older one. Closing this PR.

[mbien]

new PR is ok too of course but force pushing the branch with amended commit would also work.