Need to prepare for Guava update in JDTLS
vorburger opened this issue · 9 comments
@guw it broke for me today (was working yesterday), I'm on v1.24.103200544, and .log has this, which is likely root cause:
!SESSION 2024-03-20 19:11:45.252 -----------------------------------------------
eclipse.buildId=unknown
java.version=17.0.10
java.vendor=Eclipse Adoptium
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: --pipe=/run/user/1000/lsp-7df9ef340a6a93b5a76e149d2c9f9d0d.sock
Command-line arguments: -data /home/vorburger/.config/Code/User/workspaceStorage/5687ff7dea6a22a979f8c4dab8eb016b/redhat.java/jdt_ws --pipe=/run/user/1000/lsp-7df9ef340a6a93b5a76e149d2c9f9d0d.sock
!ENTRY com.salesforce.bazel.sdk 4 0 2024-03-20 19:11:46.180
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: com.salesforce.bazel.sdk [131]
Unresolved requirement: Require-Bundle: com.salesforce.bazel.importedsource; bundle-version="2.0.0"
-> Bundle-SymbolicName: com.salesforce.bazel.importedsource; bundle-version="2.0.0.v20240320-0533"
com.salesforce.bazel.importedsource [130]
Unresolved requirement: Import-Package: com.google.auto.value; resolution:="optional"
Unresolved requirement: Import-Package: com.google.errorprone.annotations; resolution:="optional"
Unresolved requirement: Import-Package: com.github.benmanes.caffeine.guava; version="3.1.8"
-> Export-Package: com.github.benmanes.caffeine.guava; bundle-symbolic-name="com.github.ben-manes.caffeine.guava"; bundle-version="3.1.8"; version="3.1.8"; uses:="com.github.benmanes.caffeine.cache,com.google.common.cache"
com.github.ben-manes.caffeine.guava [126]
Unresolved requirement: Import-Package: com.google.common.cache; version="[32.1.0,33.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:493)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:2073)
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:143)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2064)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2004)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1967)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1883)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:341)
This is blocking me from working on my project. I'll check out if there's a way to revert to older extension versions? (I've never tried.)
FYI My current redhat.java is v1.29.2024032008 FWIW.
'll check out if there's a way to revert to older extension versions? (I've never tried.)
I've figured out how to do this (in UI, drop-down on Uninstall Extension; bit hidden)...
... but am still seeing it on 1.24.103111607 from 3/11/2024.
FYI My current redhat.java is v1.29.2024032008 FWIW.
It's probably the JDT that changed its Guava version? Trying...
It's probably the JDT that changed its Guava version? Trying...
Yeah, right; so with this extension back to its latest (as above) BUT redhat.java on (current) release v1.28.1 instead of pre-release, it's fine.
Yeah, right; so with this extension back to its latest (as above) BUT redhat.java on (current) release v1.28.1 instead of pre-release, it's fine.
Wehl... actually, hang on - I think this means that this extension probably WILL break when Language Support for Java(TM) by Red Hat upgrades from v1.28.1 to v1.29? At that point, you'll have to bump your Guava version range in an OSGi MANIFEST as well? Perhaps you could leave it "open"? Or bundle Guava yourself, to avoid this? Just a thought / your call.
Yes. We need to prepare for an update.
I've just run into this problem again, with this extension on v1.24.104040818 (pre-release) and redhat.java v1.29.0.
this means that this extension probably WILL break when Language Support for Java(TM) by Red Hat upgrades from v1.28.1 to v1.29
@guw apparently this just (today?) happened...
I've figured out how to do this (in UI, drop-down on Uninstall Extension; bit hidden)...
Using this to downgrade redhat.java from their recent v1.29.0 release back down to 1.28.1 works around this problem.
Update needs to happen here:
Then generate new .target files in Eclipse (use this for generating) or manually update them as well.
The problem has been fixed in the upstream library but not released yet.
ben-manes/caffeine#1160
Waiting on a Caffeine release with more relaxed OSGi headers
Please remove your unnecessary usage of the guava adapter so the dependency isn’t needed, thus avoiding the problem entirely.