Check JDT Version on Startup

[tsmaeder]

Is your feature request related to a problem? Please describe.
Since vscode-gradle uses internal API from JDT (internalDefaultRootModules, for example), a new vscode-java release can break vscode-gradle. While we can improve the turn-around time on releases of vscode-gradle, we should consider checking whether the version of vscode-java and jdt is the same we're expecting.

Describe the solution you'd like
I would expect vscode-gradle to warn the user about mismatched versions and to turn off project import when the versions don't match, as it might fail anyway.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[rgrunber]

The only guarantee vscode-gradle can probably make for sure is that it supports the version of vscode-java / JDT-LS that was the latest at the time of vscode-gradle's release. So basically the extension should store latest vscode-java / JDT-LS (either one) version at build, compare to what exists at runtime and warn/no-warn users accordingly.

Either vscode.extensions.getExtension('redhat.java').packageJSON.version or you can use the fairly recent addition of server info that is part of the response to initialize.

[tsmaeder]

vscode-gradle would have to get access to that info, though as it is not talking directly to the language server.

[tsmaeder]

Background: some users have been ending up with non-functional projects because of exceptions on import. While the log shows the exceptions, it's not obvious to users how to act on that: a warning would manage expectations and let them try to fix it by turning build-server support off, for example.

[tleblanc-isatech]

Hello

I’m not sure if this is exactly the case, but I spent the whole day yesterday trying to recover my project because I thought I had broken something. After reinstalling my entire dev environment, I eventually realized the extension had just been updated. I tried everything I could, but the only solution for me was to roll back to the previous version.

If there’s a way to get things working with the latest version, I’d be very interested.

[rgrunber]

Either vscode.extensions.getExtension('redhat.java').packageJSON.version or ...

vscode-gradle would have to get access to that info, though as it is not talking directly to the language server.

Then vscode-gradle would just use the version of redhat.java (vscode-java) which is available to any extension.

[github-actions]

Hi @tsmaeder, I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

• Use the VS Code Extensions API to read the installed Java extension/JDTLS version at runtime and compare it against the version your Gradle extension was built for. For example:

  import { extensions, window } from 'vscode';
  const javaExt = extensions.getExtension('redhat.java');
  if (javaExt) {
    const expected = '1.18.0'; // your tested JDTLS version
    const actual = javaExt.packageJSON.version;
    if (actual !== expected) {
      window.showWarningMessage(
        `vscode-gradle was built for JDTLS v${expected}, but detected v${actual}. Project import is disabled.`
      );
      // skip project import
    }
  }

• Tie this check into your extension’s activation routine so it runs on startup and gracefully disables import if mismatched.

References:

• Fix for NoSuchMethodError after JDT version bump (pre-release only):
  Organize imports throws "Document does not match the AST" redhat-developer/vscode-java#4027 (comment)

Other references with low confidence

• Aligning target platform to catch JDT core version mismatches sooner (suggest moving jdt.apt.pluggable.core into snapshots):
  NoSuchMethodError on org.eclipse.jdt.internal.core.JavaProject.internalDefaultRootModules eclipse-jdtls/eclipse.jdt.ls#3401 (comment)
• How VS Code Gradle pulls an older JDT Core from 4.33 repo and suggestions to adjust the build target platform:
  NoSuchMethodError: 'void org.eclipse.jdt.internal.core.SearchableEnvironment.<init> #1694

The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!