Java images are confusing JDK installations

[brunoborges]

The Java images contain a JDK installed manually (through the image build in this repo) along with JDK(s) installed through the Java feature (SDKMan!).

This is creating confusion and even some conflicts when the user needs to change the JDK.

[samruddhikhandale]

@gauravsaini04 Can you help investigate this issue? Thanks!

[prathameshzarkar9]

Hi @samruddhikhandale ,
https://github.com/devcontainers/features/blob/main/src/java/install.sh#L208
here the requested_version is none which we are passing from the image devcontainer.json as below:
https://github.com/devcontainers/images/blob/main/src/java/.devcontainer/devcontainer.json#L7-L9

So when the version is none , feature is not installing any jdk by SDKMan. What else we have to analyse here ?

[brunoborges]

@prathameshzarkar9 assuming that I open a Java project using the default Java devcontainer, what is the correct way to get the right JDK for said project? Consider that the JDK installed is X, but the project requires JDK Y.

[prathameshzarkar9]

Hi @brunoborges ,
to install the right jdk in default java container using the java feature in devcontainer.json is as follows:

"ghcr.io/devcontainers/features/java:1": {
            "version": "Y"
        },

Here, the Y version is the version required for the project to install the right JDK

[brunoborges]

If I am already inside a dev container that was loaded with the default Java devcontainer, the easiest way for me as a Java developer to use a different JDK is to install another version with sdkman, especially because sdkman is available in the devcontainer in the first place.

@prathameshzarkar9 I'm afraid your suggestion is not idiomatic and requires one to make changes (or a brand new configuration) of devcontainer metadata in a repo the user may not even have write permission (thus, requiring a fork).

[samruddhikhandale]

Due to historical reasons, we have always installed Microsoft's OpenJDK in the image, and the Java feature installs sdkman. We understand the confusion this might have caused. However, changing the behavior now would be a breaking change, as this setup has been deployed in this way for many years, and users might depend on either JDK.

We appreciate your feedback. Let's keep this issue open until we receive more similar user feedback. Thanks!