Is the JDK provider customizable?

[aalmiray]

The readme does not give out details how the JDK is chosen nor from which location.
Is it always the same provider? If so, can it be customized?

[maxandersen]

We use adoptjdk. Not currently customizable as we need it to work via bash and windows batch scripts.

[aalmiray]

Can it be made customizable? Lots of JDK options available from SDKMAN! for example, all of them readily available via downloadable zip 😏

[maxandersen]

sdkman does not have windows jdk's available...not sure its worth the troubles since you would need to have sdk man installed anyway and then you just do sdk install <java> and you are happy.

to be clear i'm not against making it customizable but doing it for something that won't work crossplatform and require something else to be installed first would increase the complexity quite a lot for very little gain ( at least thats how my perspective is at the moment ).

i.e. if there was another API available similar to openjdk that would serve out cross platform SDK's - that would be another story!

[maxandersen]

saw that https://www.azul.com/downloads/zulu-community/api/ exists which provides a similar api.

Making me wonder that if we were to make jdk provider customizable we might be better of writing a stupidly simple service that just expose enough api for us to get latest java version for a given os with given arch from a given "vendor service" ....allowing one to do:

//JAVA 14+@azul
//JAVA 14+@adoptjdk
etc.

and have a default provider setting.

...that could work..not sure would ever do it but now the idea is out there.

[maxandersen]

related to #1003

[brunoborges]

What is that allowing user to choose a different JDK from within the script, will give to said user?

More than just "let the user choose a different provider in a well documented, supported mechanism", how about "user wants and for that user must be able to use an official mechanism within jbang to allow choosing a different JDK provider".

And then, what is ?

[maxandersen]

@brunoborges I tried reading that comment multiple times but it is not parsing for me.

Are you saying we should not provide the capability of enabling choosing another distro/vendor and just stick to one (like today we use adopt) or that jbang shouldn't do it all ? or just asking what the behavior would be or ?

Help me parse the question....please :)

[brunoborges]

@maxandersen há. Yeah... I am saying that unless there is clarity on what would be the value for allowing end user choosing which JDK to use, then this feature shouldn't be implemented at all.

If anything, just let user define JAVA_HOME and jbang consumes from there, or a JDK path with some flag or whatever.

But anything more than that, IMO is overkill.

[brunoborges]

But I really can't see value in letting the script have information on which JDK to be used.

It's not like one JDK will be inherently different than another that the code would not run at all.

[maxandersen]

yes, I'm very conscious on not adding something that is better handled elsewhere.

Unfortunately some java distributions are "better" than others - especially when it comes to graphics - see processing/processing4#262

note, in all cases jbang will honor system path/java_home before choosing its own managed approach. Thats always be the case exactly for the reason we want user to be able to control it.

[maxandersen]

another one, graalvm CE can do a bunch of interesting things not available in other jdks...

[brunoborges]

Fair point with GraalVM CE.

[aalmiray]

Not all JDK distributions are created equal. JBang already honors JAVA_HOME so if you have a preference for a particular JDK then simply pre-install it. Done.

But if you can't pre-install and still want a choice then JBang doesn't let you as it will choose an specific JDK vendor for you (at the moment) without giving you the option to change it.

[quintesse]

There's a new discussion about this goin on here: #1092

The idea that has come out of this is that we could provide a feature where a user could supply a shell script/executable, let's say jbang-jdk, that mimics the functionality of jbang jdk. If such a script/exe existed in the PATH, or perhaps in a special place like ~/.jbang/bin or perhaps if it was explicitly set by a config option then JBang would delegate all JDK management (including all jbang jdk handling) to that script/exe.

[quintesse]

You can actually do this now since #1500, but it's not enabled by default. The easiest way to enable it is to either pass --jdk-providers=all on the command line or set it using jbang config set run.jdkproviders all (which would set it for the run command, there are similar options for build and jdk).
Closing.

[fbricon]

How do I tell jbang that I want it to only use the JBang provided JDK, when calling jbang info tools ./hello.java, as it worked before? i.e. With a script defining //JAVA 14, it would download a JDK 14 distro, even if JDK 19 is available

[quintesse]

@fbricon are you sure your script has //JAVA 14 and not //JAVA 14+? Because I just tested it and it works as expected: //JAVA 14 requires an exact match and will download Java 14 if it isn't available. Using //JAVA 14+ on the other hand just tells Jbang that the Java version to use should be at least version 14, but it you have any later version installed it will use that one.

[fbricon]

➜  src jbang --version; jbang jdk home
0.103.1
/Users/fbricon/.sdkman/candidates/java/11.0.18-tem
➜  src bat hello.java
   1   │ //usr/bin/env jbang "$0" "$@" ; exit $?
   2   │ //DEPS com.github.lalyos:jfiglet:0.0.8
   3   │ //JAVA 14
   4   │ import com.github.lalyos.jfiglet.FigletFont;
   5   │ class hello {
   6   │   public static void main(String... args) throws Exception {
   7   │     System.out.println(FigletFont.convertOneLine("Hello InfoQ"));
   8   │   }
   9   │ }
➜  src jbang info tools --fresh --verbose  ./hello.java
[jbang] [0:275] jbang version 0.103.1
[jbang] [0:300] Resolving resource ref: ./hello.java
[jbang] [0:304] Resolved resource ref as: ./hello.java (cached as: /Users/fbricon/Dev/workspaces/committers-2023-03-M2/jbanged/src/hello.java)
[jbang] [0:322] Resolving artifact(s): com.github.lalyos:jfiglet:0.0.8
[jbang] [0:325] Repositories: mavencentral=https://repo1.maven.org/maven2/
[jbang] [0:325] Resolving dependencies...
[jbang] [0:472]    com.github.lalyos:jfiglet:0.0.8
[jbang] [0:496]    org.sonatype.oss:oss-parent:7
[jbang] [0:518] Dependencies resolved
[jbang] [0:593] Resolved artifact(s): com.github.lalyos:jfiglet:jar:0.0.8=/Users/fbricon/.m2/repository/com/github/lalyos/jfiglet/0.0.8/jfiglet-0.0.8.jar
[jbang] [1:002] Requesting HTTP GET https://api.foojay.io/disco/v3.0/distributions/temurin?latest_per_update=true
[jbang] [1:002] Headers {User-Agent=[JBang/0.103.1 (Mac OS X/13.2.1/x86_64) Java/11.0.18/Eclipse Adoptium]}
[jbang] [2:481] Downloaded file https://api.foojay.io/disco/v3.0/distributions/temurin?latest_per_update=true
[jbang] [2:483] Deleting folder /Users/fbricon/.jbang/cache/urls/0f9fcd08469c09a7a7ee5571f6c1e8c7ac8d1a1bf9b1eb194dc10cc6eef22267.old
[jbang] [2:492] Requesting HTTP GET https://api.foojay.io/disco/v3.0/distributions/aoj?latest_per_update=true
[jbang] [2:492] Headers {User-Agent=[JBang/0.103.1 (Mac OS X/13.2.1/x86_64) Java/11.0.18/Eclipse Adoptium]}
[jbang] [2:679] Downloaded file https://api.foojay.io/disco/v3.0/distributions/aoj?latest_per_update=true
[jbang] [2:679] Deleting folder /Users/fbricon/.jbang/cache/urls/c7513504fc9b7fb1fed8880e3f18d012d6a7f8d9e87864cb93a9132ab7c6d036.old
{
  "originalResource": "./hello.java",
  "backingResource": "/Users/fbricon/Dev/workspaces/committers-2023-03-M2/jbanged/src/hello.java",
  "applicationJar": "/Users/fbricon/.jbang/cache/jars/hello.java.f84d4b098ad947588207da1de993ba1f9ddce3ac8ce4c2634f561e372ec46929.jar",
  "dependencies": [
    "com.github.lalyos:jfiglet:0.0.8"
  ],
  "resolvedDependencies": [
    "/Users/fbricon/.m2/repository/com/github/lalyos/jfiglet/0.0.8/jfiglet-0.0.8.jar"
  ],
  "javaVersion": "14",
  "requestedJavaVersion": "14",
  "compileOptions": [
    "-g"
  ],
  "sources": [
    {
      "originalResource": "./hello.java",
      "backingResource": "/Users/fbricon/Dev/workspaces/committers-2023-03-M2/jbanged/src/hello.java"
    }
  ]
}

[fbricon]

With jbang 0.101.0, JBang detects 11 is incompatible with requested 14, downloads required JDK then provides the path to the JDK as "availableJdkPath": "/Users/fbricon/.jbang/cache/jdks/14"

➜  src sdk u jbang 0.101.0

Using jbang version 0.101.0 in this shell.
➜  src jbang info tools --fresh --verbose  ./hello.java
[jbang] jbang version 0.101.0
[jbang] Repositories: mavencentral=https://repo1.maven.org/maven2/
[jbang] Resolving dependencies...
[jbang]    com.github.lalyos:jfiglet:0.0.8
[jbang]    org.sonatype.oss:oss-parent:7
[jbang] Dependencies resolved
[jbang] System Java version detected as 11
[jbang] System Java version 11 incompatible, using JBang managed version 14
[jbang] Downloading JDK 14. Be patient, this can take several minutes...
[jbang] Downloading https://api.foojay.io/disco/v3.0/directuris?distro=aoj&javafx_bundled=false&libc_type=libc&archive_type=tar.gz&operating_system=mac&package_type=jdk&version=14&architecture=x64&latest=available
[jbang] Redirected to: https://github.com/AdoptOpenJDK/openjdk14-binaries/releases/download/jdk-14.0.2%2B12/OpenJDK14U-jdk_x64_mac_hotspot_14.0.2_12.tar.gz
[jbang] Redirected to: https://objects.githubusercontent.com/github-production-release-asset-2e65be/233878254/7e60c580-c74a-11ea-83fc-6a8d5fccf665?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230219%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230219T160542Z&X-Amz-Expires=300&X-Amz-Signature=4b6bca623c650347fccb31a8c9e8d83a3418712f5500585c5c460b61953416c8&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=233878254&response-content-disposition=attachment%3B%20filename%3DOpenJDK14U-jdk_x64_mac_hotspot_14.0.2_12.tar.gz&response-content-type=application%2Foctet-stream
[jbang] Downloaded file https://objects.githubusercontent.com/github-production-release-asset-2e65be/233878254/7e60c580-c74a-11ea-83fc-6a8d5fccf665?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230219%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230219T160542Z&X-Amz-Expires=300&X-Amz-Signature=4b6bca623c650347fccb31a8c9e8d83a3418712f5500585c5c460b61953416c8&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=233878254&response-content-disposition=attachment%3B%20filename%3DOpenJDK14U-jdk_x64_mac_hotspot_14.0.2_12.tar.gz&response-content-type=application%2Foctet-stream
[jbang] Installing JDK 14...
[jbang] Unpacking to /Users/fbricon/.jbang/cache/jdks/14
{
  "originalResource": "./hello.java",
  "backingResource": "/Users/fbricon/Dev/workspaces/committers-2023-03-M2/jbanged/src/hello.java",
  "applicationJar": "/Users/fbricon/.jbang/cache/jars/hello.java.f84d4b098ad947588207da1de993ba1f9ddce3ac8ce4c2634f561e372ec46929.jar",
  "dependencies": [
    "com.github.lalyos:jfiglet:0.0.8"
  ],
  "resolvedDependencies": [
    "/Users/fbricon/.m2/repository/com/github/lalyos/jfiglet/0.0.8/jfiglet-0.0.8.jar"
  ],
  "javaVersion": "14",
  "requestedJavaVersion": "14",
  "availableJdkPath": "/Users/fbricon/.jbang/cache/jdks/14",
  "compileOptions": [
    "-g"
  ],
  "sources": [
    {
      "originalResource": "./hello.java",
      "backingResource": "/Users/fbricon/Dev/workspaces/committers-2023-03-M2/jbanged/src/hello.java"
    }
  ]
}

availableJdkPath is not returned in 0.103.1

[maxandersen]

Which version of jbang works as you expect @fbricon ?

[fbricon]

0.101.0, as per my last comment

[fbricon]

this affects jbang-eclipse/jbang-vscode which relies on the availableJdkPath value to set the proper JDK

[maxandersen]

Okey so it's not necessarily about missing download but that info tools does not seem to even add the jdk info to the output.

That's definitely a regression.

[fbricon]

Well that's 2 regressions then :-)

[quintesse]

availableJdkPath is not returned in 0.103.1

It's not returned because it's not installed :-)

And info tools was indeed changed to not download and install an entire JDK automatically when it's not needed for the functioning of the info command.

If that information is necessary for the functioning of the plugin, I suggest we make it a multi-step process. I see several options:

• Run info tools, if availableJdkPath is not set then run jdk home <X> with the value of requestedJavaVersion, it will install the JDK and return its path, or
• Run info tools, if availableJdkPath is not set then run build and finally run info tools again, or
• Always run build before running info tools

[maxandersen]

It is required for it to work similar to how it also fetch dependencies before returning the list of deps?

[quintesse]

Ok, we'll make info tools download JDKs again, see: #1569