Improve first-time / new user experience

[bagrupe]

I am teaching classes and recently switched from eclipse to vscode-java as the editor/IDE of choice in those classes. However, due to the recent JDK chaos (multiple OpenJDK distros, quick releases, LTS, non-LTS) and a few vscode quirks it has gotten fairly complicated to cleanly set up all my students’ vscodes.

Here are some questions and suggestions on how to improve the first-time experience:

• JDK handling: it would be quite neat if the extension downloads a ‘private copy’ of a JDK on first start (bundling it would bloat the download size too much I think) so that jdt.ls always has a private copy of it and doesn’t need to rely on java.home
• Furthermore it would be great to enable relative Paths for settings like java.home and java.configuration.runtimes so that I could create a vscode workspace with a local JDK for my students
• Launch the extension when opening a workspace containing java projects and not on first-open of a *.java file: I know it may be beneficial in some situations to lazy load the extension but for my use case it would be great to be able to autoload it (preferably with a *.vscode-workspace level setting). Right now my problem is that all java commands in the command palette are available but don’t work unless a java file has been opened and jot.ls has started
• The command “Java: Clean the java language workspace” must be executed way too often and the detection when to do it isn’t good enough just yet: If you change settings directly in settings.json, depending if the server has been started or not, you won’t get a notification to do it and the language server will be in some sort of undefined state, even if you close and restart vscode. My quick fix suggestion would be to enhance the detection of changes (basically if any java.* changed suggest to clean the workspace)
• Additionally, sometimes you’ll get the message that a java file is out-of-project and only syntax errors are reported while it is clearly inside a maven project (jdt.ls must have somewhat corrupted the workspace), is it possible to add a detection that if there’s a maven/gradle project present to also suggest to clean the workspace instead of silently failing?

Keep up the good work! If you need further info on those subjects please let me know.

Environment

• Operating System: any
• JDK version: any
• Visual Studio Code version: 1.50.1
• Java extension version: 0.69.0

[testforstephen]

@bagrupe Really great feedback. thanks.

• Regarding the JDK setup issue, we also provide a coding-pack-for-Java installer to simplify the Java env setup. The installer will install the right JDK and Java extensions on demand. You could have a try on it.
• VS Code just provides a fixed group of events to activate the extension. There is no mechanism to activate it on workspace setting. Based on current mechanism, the Java extension only auto load if your workspace root contains a pom.xml or build.gradle. If it's not the case, then open .java file will activate the extension. Could you share your scenario why you have to run some Java commands before it activates?
• What specific problems you got when you changed the java.* user setting?
• a java file is out-of-project and only syntax errors are reported means the opened file is not on the source path. If you're opening a Java file under src/java/main folder of your Maven project, that must be a bug, and please share us a sample to reproduce.

[bagrupe]

@testforstephen Thanks for the comment, this is my follow-up:

• I wanted to lock the JDK to Azul Zulu Community 11 but some students had OpenJDK 14/15 installed due to a previous course, so the coding-pack installer correctly assumed a fitting JDK is available and set java.home to it - I haven't found detailed documentation/source of the installer, is it available on github? That way I could even try to do a customized installer
• I see, I have created a multi-root workspace with a parent pom.xml in a subfolder not the root folder, that's why it didn't trigger automatically. I had problems with a pom.xml in the root folder in the past (not all the projects are modules in the parent pom and they will under certain circumstances get ignored then) - would it be possible to add an additional magic file which is independent of a build system to trigger the extension to load?
• The problems when directly editing those settings in the settings.json file were an 'out-of-sync' jdt.ls workspace, it tried to e.g. build the project with OpenJDK 14 even though the java.home was switched to JDK 11. That only happened when the settings were changed when the language server wasn't already running
• Yes, those were under src/main/java and mostly occur when not using the maven -> add project wizard but when you copy an existing maven project into your workspace. I'll try to create a minimal repro later today.

[testforstephen]

• @Eskibear is the author of the installer, he could provide more details about the installer.
• A magic file is a workable idea. So far, the Java extension will auto load if your root contains pom.xml, build.gradle or .classpath. For your case, you could add a fake empty .classpath file in your root to make the extension to be activated on startup. But you need be cautious about this. You shouldn't manually add .classpath file if your root already contains some explicit build descriptor file such as pom.xml or build.gradle.
• This is a good corner case. Could you help open a separate bug for this?
• Looks like the Java extension doesn't import the newly added maven project automatically. There is a new command "Java: Import Java projects in workspace" to explicitly import the new projects.

[bagrupe]

• Okay, thanks, I hope he'll read this issue now that he is pinged
• Should I also open a separate issue for the new magic file? How should it be named if so?
• I'll open an issue for the corner case
• Okay, thanks, is it planned to let it check/do that automatically in the future?

[testforstephen]

• For the magic file, i assume you already could leverage .classpath as a magic file for your case. We won't invent a new magic file unless there are more use cases for it.
• About auto detect new projects, worth a new issue to track it.

[Eskibear]

the coding-pack installer correctly assumed a fitting JDK is available and set java.home to it - I haven't found detailed documentation/source of the installer, is it available on github?

The original goal of the Coding Pack is to help install the minimum requirements for vscode Java. It will detect JDKs installed and point java.home to the latest one if its major version is > 11. Otherwise it will download and install AdoptOpenJDK 11.
Actually java.home doesn't matter much to your projects, it's used to launch Java Language Server. As you mentioned, I myself agree that ultimately java.home should be removed, and we pre-pack/download the JDK to launch itself. (as far as I know IntelliJ IDEA packs a "private distribution" inside to launch itself).

It's not opensourced, but we do have a Github repo for issue tracking. https://github.com/microsoft/vscode-java-installer

[marlemie]

Just to chime in regarding the out of project error. I had the same error in a project as simple as it gets:

I am just starting with Java so I want to keep it as simple as possible at the moment. I started the project with an "incorrect" folder structure, moved the files around a bit until it was correct, but then was faced with the "not on the classpath of project" error message. Only cleaning the workspace helped.

[indexlongrun]

Hi @Eskibear I wanted to give a windows user perspective.
I'm an experienced Java developer and I really like VS Code but installing the java plugin has proven very challenging.

The original goal of the Coding Pack is to help install the minimum requirements for vscode Java. It will detect JDKs installed and point java.home to the latest one if its major version is > 11. Otherwise it will download and install AdoptOpenJDK 11.

I have the coding pack installed but I still get this message:

So nothing is automatic here.
When I follow the link to download I reach the download of the 1.8 jdk which is the wrong version.
After finding the right version and manually installing it with the default settings VS code is still not able to find and use it.

[Eskibear]

@indexlongrun Thank you for the feedback!

I have the coding pack installed but I still get this message:

Did the coding pack install a JDK 11 for you? I guess that before installing the coding pack, you already have a JDK 8 installed on your machine, and JAVA_HOME is pointing to it. Let me know if I'm right.

After finding the right version and manually installing it with the default settings VS code is still not able to find and use it.

True, the JDK detection should be improved. It's tracked in #1621 . To work it around for the moment, you have to manually set java.home to a JDK 11+. We are also exploring ways to guide you, e.g. via some GUI you can one-click to configure that.

[indexlongrun]

@Eskibear, thank you for your attention and response

Did the coding pack install a JDK 11 for you?

No

I guess that before installing the coding pack, you already have a JDK 8 installed on your machine, and JAVA_HOME is pointing to it. Let me know if I'm right.

Yes, you are correct.

Adding my two cents:
The process in question is to install a JDK 11 or higher to enable the Java extension. This means that the user most likely dose not yet have any Java projects running in vs code.
At this point the user is more concerned with installing the Java extension than compiling future projects with old JDKs.
I would suggest updating the message and focusing on the java.home setting since it is something that the user must currently update to use the extension.

[deftdawg]

I'm also seeing this "java.configuration.runtimes" on a machine with Mac with openJDK 15 installed via brew.

Detected JDKs just spins infinitely; don't get why it doesn't lookup the PATH JDK location w/java -XshowSettings:properties -version 2>&1 | grep java.home and assuming it contains a proper bin/javac default to that location?

[Eskibear]

@deftdawg
We do check PATH for javac, and it might be a bug in your case.
Please open an issue https://github.com/microsoft/vscode-java-pack/issues , providing OS version (Big Sur?), how you install JDK 15(looks like homebrew?), any other JDK installed, value of $PATH and $JAVA_HOME. Thanks.

Currently you can simply point setting java.home to the path in your screenshot to work it around.