Java 17 for workspace-full

[jalexcole]

Is your feature request related to a problem? Please describe

redhat.java pushed an update requiring java 17 be set up in the homepath. The default jdk is 11, there for the main java extensions do not work unless java 17 is installed.

Describe the behaviour you'd like

I would recommend moving workspace-full to default at java 17 due to the vscjava.vscode-java-pack provided by redhat vscjava

Describe alternatives you've considered

Manually configuring the home path in each docker file with java 17 installed. Increases time for start up.

Additional context

Extension Notification: "Activating extension 'redhat.java' failed: Java 17 or more recent is required to run the Java extension. Please download and install a recent JDK. You can still compile your projects with older JDKs by configuring 'java.configuration.runtimes'."

[axonasif]

See #845 (comment)

[jalexcole]

After reading through the #845 (comment), I understand that breaking changes may occur to the project due to jdk 8 and 11 compatibility, however I think the question should be: do we start having plugins incompatible that limit the use case and require more effort or be compatible with older projects. I think the in this case it would be better for java 17 to come by default and if a specific version is needed one could specify in their .gitpod.Dockerfile a sdk install of their required version of java to be installed alongside.

[axonasif]

@jalexcole you can use image: gitpod/workspace-java-17:2022-06-20-19-54-55 (tag 2022-06-20-19-54-55 taken from here) on your .gitpod.yml. Then you can see in action 😉

[jalexcole]

@jalexcole you can use image: gitpod/workspace-java-17:2022-06-20-19-54-55 (tag 2022-06-20-19-54-55 taken from here) on your .gitpod.yml. Then you can see in action 😉

This solution does not seem to work.

[axonasif]

That seems weird, what's actually going wrong?

[jalexcole]

I figured it out last night. Apparently for changes in the yaml file unless one goes all the way back to the dashboard when closing the workspace instead of restarting it in the half way screen. To solve it from there:

• before: yes | sdk install java 17.0.3-zulu

I think however if someone wants a previous version of java they should specify that they want it.

@axonasif There was an issue where I had to go all the way out to the workspace dashboard and not just hit stop workspace.

[axonasif]

Its recommended to use custom dockerfiles for such heavy tasks to save you time.

[akosyakov]

Did anyone try to add java 17 to java layer additionally to java 11? Maybe VS Code java is smart enough to found a necessary one without us breaking user apps requiring java 11?

[jeanp413]

This will be fixed by deploying openvsx, platform specific extension got implemented months ago, but is not deployed yet 🤦

Maybe VS Code java is smart enough to found a necessary one without us breaking user apps requiring java 11?

In the wiki it says it will search in JDK_HOME and JAVA_HOME but those will be pointing to jdk 11, only way is to manually configure in the settings.json using java.jdt.ls.java.home in that case I'll say just use a custom dockerfile for now until we get openvsx deployed Took a look at the code and it should also detect additional installations by scanning multiple locations using https://github.com/Eskibear/node-jdk-utils

[jalexcole]

I think I would like to move the discussion of the issue as more philosophical. The fix is easy enough to require in the dockerfile, however what should the out of the box experience be for anyone starting a project in gitpod? Should a java developer try out spring pet clinic and realize that none of the plugins work and then have to go through and trouble shoot it or should they be able to make changes right then and there and have all of their favorite tools.

[loujaybee]

Please note this is blocked / dependent upon:

• Epic: Improve versioning and rollout of workspace images gitpod#10683

[loujaybee]

Update, this is being investigated for possibility to do this in a backwards compatible fashion in:

• Experiment with 2 Java versions in the full image #888