[GR-79054] Espresso stalls during Equinox bundle activation while starting Eclipse JDT LS

[mingchiuli]

Describe the issue

Eclipse JDT Language Server fails to initialize when it is launched with Espresso Java 25 on macOS.

The JDT LS initialization request eventually times out after 120 seconds. During startup, Espresso reports that it failed to link the Equinox native splash method:

[java] WARNING: Failed to link native method:
EspressoMethod<Lorg/eclipse/equinox/launcher/JNIBridge;._update_splash()V>

The same JDT LS installation starts normally when JAVA_HOME points to a standard Oracle GraalVM / HotSpot Java 25 installation.

Environment

• Operating system: macOS, Apple Silicon (aarch64)
• Espresso:
  • Java version: 25
  • Distribution: espresso-java25-25.0.0-macos-aarch64
• Working JVM:
  • Oracle GraalVM 25.2.4
  • Java 25.0.4
  • HotSpot VM
• Eclipse JDT LS: 1.58.0-202604151538
• Client: Zed with Java extension 6.8.24

Espresso reports:

java version "25"
Espresso 64-Bit VM (build 25-espresso-25.0.0)

The working JVM reports:

java version "25.0.4"
Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 25.2.4+7.1

Steps to reproduce

1. Install Eclipse JDT Language Server 1.58.0-202604151538.

2. Set JAVA_HOME to Espresso:

   export JAVA_HOME="/Library/Java/JavaVirtualMachines/espresso-java25-25.0.0-macos-aarch64"

3. Start JDT LS using its bin/jdtls launcher.

4. Send the LSP initialize request.

Actual behavior

JDT LS does not finish initialization. The client times out after 120 seconds:

Cancelled LSP request task for "initialize" id 0 which took over 120s
Failed to start language server "jdtls"
Request timed out

Espresso also logs:

[java] WARNING: Failed to link native method:
EspressoMethod<Lorg/eclipse/equinox/launcher/JNIBridge;._update_splash()V>

The stalled JDT LS process remains running after the timeout.

Expected behavior

JDT LS should initialize successfully under Espresso, or Espresso should handle the optional Equinox splash-screen JNI method without preventing Eclipse/Equinox startup.

Workaround

Configure JDT LS to use a standard HotSpot-based JVM:

{
  "java_home": "/Library/Java/JavaVirtualMachines/graalvm-25.2.4+7.1/Contents/Home"
}

With this change, the same JDT LS installation and workspace initialize normally.

Additional information

The failure appears related to the Equinox launcher JNI bridge:

org.eclipse.equinox.launcher.JNIBridge._update_splash()

No matching issue was found in the Graal, Eclipse JDT LS, or Zed Java extension issue trackers.

Please let me know if an Espresso trace or a minimal standalone Equinox reproduction would be useful.

[oubidar-Abderrahim]

Thank you for reporting this, I believe a minimal reproducer would be helpful

[gilles-duboscq]

I had a quick look on linux and couldn't reproduce. Maybe this only reproduces on macos? Could you give it a try @lewurm?

[mingchiuli]

Thank you for reporting this, I believe a minimal reproducer would be helpful

I investigated this further and confirmed that the issue still reproduces with Espresso 25.1.3 and JDT LS 1.60.0 on macOS aarch64.

Using an empty workspace and sending initialize directly over stdio:

• Espresso: no response after 90 seconds
• HotSpot: response in about 1.2 seconds
• Espresso with the syntax-server configuration: response in about 5 seconds

The JNIBridge._update_splash() warning does not appear to be the cause:

• JNIBridge.updateSplash() ultimately succeeds after Equinox loads its native library.
• The aarch64 launcher library exports the expected JNI symbol.
• -nosplash removes the warning, but JDT LS still hangs.

Bundle isolation shows that removing the m2e bundles allows Espresso to initialize. A minimized failing configuration requires the combination of:

• m2e/Plexus
• Aries SPI Fly and its ASM dependencies
• SLF4J with logback

The same minimized configuration initializes under HotSpot in 877 ms but stalls under Espresso.

During the stall, m2e is creating a Plexus container through Guice/Sisu and OSGi class loading. Other threads wait in Module.lockStateChange for org.eclipse.core.resources, whose state-transition lock is held by the Equinox Start Level thread.

I also tested the fix from eclipse-m2e/m2e-core#2217. The patched class was loaded, but Espresso still stalled, so the known m2e lock inversion may contribute to the timing but is not the complete cause.

This looks like an Espresso-specific problem during concurrent Equinox bundle activation on macOS, rather than a splash-screen JNI failure. A more accurate title may be:

[GR-79054] Espresso stalls during Equinox bundle activation while starting Eclipse JDT LS on macOS

[gilles-duboscq]

OK thanks for the macos detail, that matches what i see on linux.

I have already looked into the stalling issue which is also present on linux. There is a dead-lock related to espresso's constant pool implementation.