vscode-java: Fall back to java.jdt.ls.java.home if embedded JRE fails

When deploying VSCode to an AP Computer Science lab where the students don’t have admin privileges, attempts to enable the latest Extension Pack for Java (which includes the “Language Support for Java™ by Red Hat” extension) fail reporting “Couldn’t start client Language Support for Java” whenever they open a Java project.

Environment
  • Operating System: Windows 10
  • JDK version: Various (tried latest Microsoft OpenJDK 11 & 17 as well as those from Adoptium’s Teemurin)
  • Visual Studio Code version: 1.64.0
  • Java extension version: v 1.1.0 through v1.3.0
Steps To Reproduce
  1. Install latest VSCode and JDK (with JAVA_HOME set correctly)
  2. Create a new Java class
Current Result

Reports “Couldn’t start client Language Support for Java” when trying to run or debug the Java code.

Expected Result

Should work like it does for users with admin privileges (or how it did for v1.0.0).

Additional Information

Works fine for users with admin privileges or if we roll the students back to v1.0.0 of this extension. Typing java -version in terminal returns correct OpenJDK version.

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Comments: 17 (9 by maintainers)

Most upvoted comments

Renamed this so at least we can track it. Probably lower priority given a solution exists, but at least we can revisit in the future.

So, it appears that the Red Hat Java extension was getting blocked by AppLocker. We’ve worked around it by updating AppLocker policies to allow any executable in this path: c:\users*.vscode\extensions\redhat.java*

However, this workaround has only been approved for our lab machines. If the school district allows this group policy change onto student laptops, we would eventually find students putting their own executables (games, malware, unapproved software, etc.) off c:\users*.vscode\extensions\redhat.java*. and running them. (Even students that don’t have VSCode would be able to do that when their friends find the loophole and pass it along.) The policy change has only been approved for the labs because it’s a supervised environment that can be a little looser.

Can you help me understand how the extension’s behavior changed after v1.0.0? We really need to allow our AP CS students to use VSCode on their student laptops from home or during study halls, but we also need to make it work without adding loopholes for students to run their own executables. Was that loophole still there with the 1.0.0 ts-loader but AppLocker just wasn’t catching it?

However, I was able to grab this log by downgrading to v.1.0.0 first and then upgrading to v1.3.0. client.log.2022-02-09.txt