Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JDK lookups should include sdkman installed JDKs #1476

Open
jeffmaury opened this issue Oct 6, 2022 · 12 comments
Open

JDK lookups should include sdkman installed JDKs #1476

jeffmaury opened this issue Oct 6, 2022 · 12 comments
Labels
ideas Some idea/suggestion around jbang behavior/feature set

Comments

@jeffmaury
Copy link
Contributor

Is your feature request related to a problem? Please describe.
When a specific version of Java is required for a script, the JDK installed by sdkman should be looked

Describe the solution you'd like
I had Java 17.0.3 installed by sdkman and ran https://raw.githubusercontent.com/maxandersen/gh-jtriage/main/jtriage.java but jbang says Downloading JDK 16.
Not mentioning permission issues on Windows

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

@jeffmaury jeffmaury added the ideas Some idea/suggestion around jbang behavior/feature set label Oct 6, 2022
@quintesse
Copy link
Contributor

quintesse commented Oct 6, 2022

@jeffmaury can you tell us exactly which JDK you have installed using sdkman?

And if possible can you see if that installed JDK has a release file in its root folder? And if so could you paste its contents?

Edit: Oh, and to be sure, if you type java -version in a terminal you get that 17..0.3 version, right?

@maxandersen
Copy link
Collaborator

@jeffmaury is your case you don't have that java 17 from sdkman in path and you expect jbang to go search on local disk for alternative sdk installs?

If yes then I'm not convinced that will provide a consistent behavior as sdkman has no notion of ordering of its jdks.

You can if you want tell jbang about specific version of jdk to use:

"jbang jdk install 17 sdk home java 17.0.4.1-tem"

@jeffmaury
Copy link
Contributor Author

@jeffmaury can you tell us exactly which JDK you have installed using sdkman?

And if possible can you see if that installed JDK has a release file in its root folder? And if so could you paste its contents?

Edit: Oh, and to be sure, if you type java -version in a terminal you get that 17..0.3 version, right?

I was running JBang with Java11.
I had:

  • 8.0.302-tem
  • 11.0.16.1-tem
  • 17.0.3-tem
  • 21.3.0.r11-grl

installed with sdkman.
17.0.3-tem has the following release file:


IMPLEMENTOR="Eclipse Adoptium"
IMPLEMENTOR_VERSION="Temurin-17.0.3+7"
JAVA_VERSION="17.0.3"
JAVA_VERSION_DATE="2022-04-19"
LIBC="default"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.incubator.foreign jdk.incubator.vector jdk.internal.le jdk.internal.opt jdk.internal.vm.ci jdk.internal.vm.compiler jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jpackage jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.nio.mapmode jdk.random jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Windows"
SOURCE=".:git:9190d7016e2b"
BUILD_SOURCE="git:955033f"
BUILD_SOURCE_REPO="https://github.com/adoptium/temurin-build.git"
SOURCE_REPO="https://github.com/adoptium/jdk17u.git"
FULL_VERSION="17.0.3+7"
SEMANTIC_VERSION="17.0.3+7"
BUILD_INFO="OS: Windows Server 2012 R2 Version: 6.3"
JVM_VARIANT="Hotspot"
JVM_VERSION="17.0.3+7"
IMAGE_TYPE="JDK"

@maxandersen
Copy link
Collaborator

Yes. So by you having java 11 in path that is what jbang will use and if does not fit it will fetch one of the adoptium installs via foojay api.

there is no (sane) way for us to pick a reliable java version from sdkman as it has no ordering nor priority and multiple product variations.

@jeffmaury
Copy link
Contributor Author

Why don't you search in $HOME/.sdkman/candidates/java based on the release file @quintesse mentioned ?

@maxandersen
Copy link
Collaborator

@jeffmaury here is what is in my sdkman:

8.0.262.hs-adpt
8.0.265.hs-adpt
8.0.322-zulu
11.0.2-open
11.0.9.hs-adpt
11.0.11.hs-adpt
14.0.2-open
14.0.2-sapmchn
14.0.2-zulu
14.0.2.fx-librca
14.0.2.hs-adpt
14.0.2.j9-adpt
16.0.2-sem
16.ea.31-open
16.ea.36-open
17-open
17.0.4.1-tem
18-open
19-open
19.ea.1.lm-open
19.ea.12-open
20.1.0.r11-grl
21.0.0.r11-grl
21.1.0.r16-grl
21.2.0.r16-grl
22.1.0.r17-grl
current -> 17.0.4.1-tem

which version do you suggest we should we pick for Java 16+ ?

@jeffmaury
Copy link
Contributor Author

@jeffmaury here is what is in my sdkman:

8.0.262.hs-adpt
8.0.265.hs-adpt
8.0.322-zulu
11.0.2-open
11.0.9.hs-adpt
11.0.11.hs-adpt
14.0.2-open
14.0.2-sapmchn
14.0.2-zulu
14.0.2.fx-librca
14.0.2.hs-adpt
14.0.2.j9-adpt
16.0.2-sem
16.ea.31-open
16.ea.36-open
17-open
17.0.4.1-tem
18-open
19-open
19.ea.1.lm-open
19.ea.12-open
20.1.0.r11-grl
21.0.0.r11-grl
21.1.0.r16-grl
21.2.0.r16-grl
22.1.0.r17-grl
current -> 17.0.4.1-tem

which version do you suggest we should we pick for Java 16+ ?

I would check current first (but it's likely going to fail as it's probably the one used to run JBang) then retrieve the versions from other candidates, sort them according to semver and select the first compatibile

@maxandersen
Copy link
Collaborator

@jeffmaury that is slow, and how to choose between using graal vs open vs temurin vs librca ... it just not worth applying this complexity on all jbang users.

you can write a script that syncs sdkman installs into jbang if users want that. Happy to add that to jbang-catalog if you wanna contribute it?

@jeffmaury
Copy link
Contributor Author

@jeffmaury that is slow, and how to choose between using graal vs open vs temurin vs librca ... it just not worth applying this complexity on all jbang users.
That is much faster than downloading a JDK when you have one on your machine 😄

you can write a script that syncs sdkman installs into jbang if users want that. Happy to add that to jbang-catalog if you wanna contribute it?
Will do

@quintesse
Copy link
Contributor

This was implemented by #1500

But for now it still only works when explicitly enabling the sdkman provider. I that perhaps something we should think about changing @maxandersen and make scoop and sdkman enabled by default?

@maxandersen
Copy link
Collaborator

We still don't have a notion of installing from those so can make them default can we ?

@quintesse
Copy link
Contributor

We still don't have a notion of installing from those so can make them default can we ?

I don't think we need to be able to install, it would be enough to use those JDKs. Activating those providers means that any JDKs that are installed can be used. Only if a specific Java version is requested that isn't available on the system will JBang use the default (Adoption) provider to install.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ideas Some idea/suggestion around jbang behavior/feature set
Projects
None yet
Development

No branches or pull requests

3 participants