Skip to content

Improve first-time / new user experience #1672

Closed
Closed
Improve first-time / new user experience#1672
Assignees
Eskibeartestforstephen
Labels
staleux

Description

@bagrupe
bagrupe
opened on Oct 24, 2020

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

Activity

  1. testforstephen commented on Oct 26, 2020

    @testforstephen
    testforstephen
    on Oct 26, 2020
    Collaborator

    @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.

  2. bagrupe commented on Oct 26, 2020

    @bagrupe
    bagrupe
    on Oct 26, 2020
    Author

    @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.

  3. testforstephen commented on Oct 26, 2020

    @testforstephen
    testforstephen
    on Oct 26, 2020
    Collaborator
    • @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.

  4. bagrupe commented on Oct 26, 2020

    @bagrupe
    bagrupe
    on Oct 26, 2020
    Author
    • 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?

  5. testforstephen commented on Oct 26, 2020

    @testforstephen
    testforstephen
    on Oct 26, 2020
    Collaborator
    • 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.

  6. Eskibear commented on Oct 28, 2020

    @Eskibear
    Eskibear
    on Oct 28, 2020
    Contributor

    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

  7. marlemie commented on Oct 28, 2020

    @marlemie
    marlemie
    on Oct 28, 2020

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

    image

    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.

  8. indexlongrun commented on Oct 29, 2020

    @indexlongrun
    indexlongrun
    on Oct 29, 2020

    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:
    image
    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.

  9. Eskibear commented on Oct 29, 2020

    @Eskibear
    Eskibear
    on Oct 29, 2020
    Contributor

    @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.

  10. indexlongrun commented on Oct 29, 2020

    @indexlongrun
    indexlongrun
    on Oct 29, 2020

    @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.

  11. deftdawg commented on Dec 10, 2020

    @deftdawg
    deftdawg
    on Dec 10, 2020

    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?

    image

  12. Eskibear commented on Dec 10, 2020

    @Eskibear
    Eskibear
    on Dec 10, 2020
    Contributor

    @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.

  13. testforstephen
    assigned
    testforstephen
    and
    Eskibear
    on Dec 18, 2020
  14. testforstephen
    added
    ux
    on Feb 13, 2023

  15. Eskibear commented on Sep 17, 2026

    @Eskibear
    Eskibear
    on Sep 17, 2026
    Contributor

    close as stale?

  16. datho7561
    added
    stale
    on Sep 18, 2026
  17. datho7561
    closed this as completedon Sep 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

staleux

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions