redhat-developer / redhat-developer/vscode-java

java has been set to 11 as default

Open
#3,136 12 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
2.3k
Forks
546
Avg merge
20h 1m
Merged PRs (30d)
11

Description

Environment
  • Operating System: Ubuntu 20.04
  • JDK version: 8/11/17
  • Visual Studio Code version: 1.78.2
  • Java extension version: 0.25.11 (Extension pack for java)
Steps To Reproduce
  1. install java 17 (upgrade alternative to it)
  2. go to https://start.spring.io/ -> Gradle Groovy, Java, 3.1.0, jar, 17 and generate
  3. open it in vscode
Current Result

org.springframework.boot.gradle 3.1.0 can't be resolved,
(Incompatible because this component declares an API of a component compatible with Java 17 and the consumer needed a runtime of a component compatible with Java 11
- Other compatible attribute:
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs))
the language support plugin is uses java 11 as default to import, even if the seourceCompatibility has been set and
the gradle.properties org.gradle.java.home=/usr/lib/jvm/java-17-openjdk-amd64 on project level has been set (root folder)

The only way was to resolve is "java.import.gradle.java.home": "/usr/lib/jvm/java-1.17.0-openjdk-amd64", which is painful to figure out, intellij is behaving similarly (Gradle JVM needs to be set -> hasn't tested the gradle.properties in this case)

Expected Result

I would have expected:
a) whatever the JAVA_HOME sais, and the java.import.gradle.java.home is not set,
it's using the JAVA_HOME for gradle import also. (command line is using it)
b) if gradle.properties has been set is picking up java folder from there

It is the behavior being described in the official gradle manual.

Additional Informations

I'm using gradle for java plugin also.
The difference between intellij and vscode was, that the Gradle JVM had a default value. (randomly selected one)

After several attempt and screw up, cleaning up language server (ctrl+shift+p -> relevant command) didn't help, just removing all the workspace folder,
remove the project from workspace and restart and add back the project.

In this case java classes has been identified as non-project files!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the Gradle Groovy project from start.spring.io with Java 17, then inspect how java.import.gradle.java.home, JAVA_HOME, and the project gradle.properties are selected during import. Done means the extension uses the expected Java 17 runtime without requiring the explicit setting and recognizes the Java classes as project files.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
build-system, devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.