redhat-developer
JRE path as environment variable
Hello, is there an environment variable to get the full JRE path for the extension? Specifically, when referencing from a devcontainer.json or settings.json file. Below is a path I'm talking about.
.vscode-server/extensions/redhat.java-1.40.0-linux-x64/jre/21.0.6-linux-x86_64/
For reference, I am creating a Dev Container for my team, which are using different OSs. The container will be using an older JRE version that some plugins won't support. I want to be able to reference the vscode-java JRE path in different settings without having to figure out the path after install.
For example, I am using Redhat's Community Server Connectors. In it, I have to define the java home rsp-ui.rsp.java.home. Currently, I pass the following if a user is on Windows
"rsp-ui.rsp.java.home": "/home/${localEnv:USERNAME}/.vscode-server/extensions/redhat.java-1.40.0-linux-x64/jre/21.0.6-linux-x86_64/"
but on Macs I have to do
"rsp-ui.rsp.java.home": "/home/${localEnv:USER}/.vscode-server/extensions/redhat.java-1.40.0-linux-arm64/jre/21.0.6-linux-aarch64/"
If there's a way to get that path without having to look it up, it'd be very useful.
Does ${localEnv:USER} (or any defined environment variable) work for you in the settings.json ? As far as I know this probably doesn't work there. In fact that's the subject of https://github.com/redhat-developer/vscode-java/issues/3976 . The problem is VS Code doesn't resolve them, or offer a nice way for extensions to do the resolution.
We're looking to use https://www.npmjs.com/package/vscode-variables , which would be done with ${env:<variable>}. Once that's done, it should be possible to define our own variables and resolve them as wanted.
@rgrunber, you are correct ${localEnv:USER} doesn't work in the settings.json file. I think that's strictly a devcontainer.json variable too.
I'll keep an eye out for any updates and test them out if/when available. Thanks!
I'll leave this open since it's different from https://github.com/redhat-developer/vscode-java/issues/3976, but that's probably where this will start to get addressed.