Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use default JVM when importing gradle project #1426

Closed
jakegt1 opened this issue Apr 30, 2020 · 6 comments · Fixed by eclipse-jdtls/eclipse.jdt.ls#1430
Closed

Use default JVM when importing gradle project #1426

jakegt1 opened this issue Apr 30, 2020 · 6 comments · Fixed by eclipse-jdtls/eclipse.jdt.ls#1430

Comments

@jakegt1
Copy link

jakegt1 commented Apr 30, 2020

So, i have a gradle project and have set the following configuration:

{
    "java.configuration.runtimes": [
        {
          "name": "JavaSE-1.8",
          "path": "path/to/jdk8",
          "default": true
        }
    ],
    "java.home": "/path/to/jdk11"
}

However, my problems section is complaining about missing the javax classes which were removed after java 8, indicating that it's not using jdk 8.

Environment
  • Operating System: Linux
  • JDK version: 11/8
  • Visual Studio Code version: 1.44.2
  • Java extension version: 0.60.0
Steps To Reproduce
  1. Set java.home to JDK11.
  2. Set java.configurations.runtime default to JDK8.
  3. See that you're not using JDK8 in problems screen.
Current Result

Doesn't use JDK8

Expected Result

Uses JDK8

Additional Informations
@fbricon
Copy link
Collaborator

fbricon commented Apr 30, 2020

Did you add

sourceCompatibility = '1.8'
targetCompatibility = '1.8'

at the root of your build.gradle (not in the compileJava block)?

@jakegt1
Copy link
Author

jakegt1 commented Apr 30, 2020

I tried this but (imo) this is not a good solution. I don't need currently to use JDK 11 for development (plus I think it's a poor idea to just assume java.home as the default if I set it manually in java.configuration.runtime.)

I set it in a subproject (not the root project) and it didn't work. Setting the comparability mode for every single project I work on is unfeasible (especially if I try to work on an old project, or a project I cannot edit.) I could manually add it every time I guess, but this is quite the pain while developing.

Is it possible to always use the default java.configuration.runtime option? Or at least have a manual setting to always use a different jdk to compile?

@jakegt1 jakegt1 closed this as completed Apr 30, 2020
@jakegt1 jakegt1 reopened this Apr 30, 2020
@jakegt1
Copy link
Author

jakegt1 commented Apr 30, 2020

Other then that, it seems awkward to do that in the root of build.gradle when the gradle docs tell you to do that differently.

EDIT: I'm guessing though this is a downstream issue that can't be fixed at vscode level?

Seems to be the case from the comment on your issue. Guess there simply is nothing I can do?

@fbricon
Copy link
Collaborator

fbricon commented May 1, 2020

  • you should definitely, define sourceCompatibility/targetCompatibility in your build.gradle, as a best practice, to ensure build reproducibility, across platforms. The fact that the compileJava block is not respected is a different, upstream issue
  • when setting JavaSE-8 as the default, it should definitely be used by default in your project, instead of Java 11. If not, then it's a bug. @snjeza did work on that part, she can investigate.

@jakegt1
Copy link
Author

jakegt1 commented May 1, 2020

I'm not saying it isn't best practice (as long as the downstream is fixed anyway), but it isn't feasible to do this for every single project in a big team.

I will start doing it in the future , but I see nothing wrong with if you set the default runtime, it should just use that one.

@snjeza snjeza changed the title Set java.configuration.runtime to default to JDK8, problems messages still seem to be using JDK 11 Use default JVM when importing gradle project May 1, 2020
@fbricon fbricon added this to the Mid May 2020 milestone May 1, 2020
@jakegt1
Copy link
Author

jakegt1 commented May 2, 2020

@fbricon @snjeza just to say thanks for the real quick turnaround on this, understand that it's pretty frustrating to support people on aging JDKs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants