Open tbee opened 3 years ago
Let me be explicit in my question: maybe someone with a working local environment can make these relatively small modifications?
With this issue, does that mean I CANNOT install a specific version of a specific JDK distribution with SDKMAN?
Not if it is no longer visible. I feel that is one of the biggest issues with sdkman; I would like the possibility list ALL versions, including the invisible ones and then install any.
That would give you an ever-expanding list of Java versions for all vendors. Simply not doable because it doesn't scale due to the combinatorial explosion.
However, if you want to reference an older version in your project through sdk env
you can do so, as the historic versions are still there, just hidden from sight.
The list view exposes all latest targets for each major version, for each vendor. This is all you should ever need if you are at least considerate of security patched releases.
I know. But there are projects that are certified to specific (major/minor) versions, it still would be nice to be able to list all available and then maybe grep over them if the list becomes unmanageable.
Thanks for the above discussions. However I still didn't get the point.
Let me clarify my case clearly.
The JDK distributions, exactly Tencent Kona JDKs, just were integrated to SDKMAN. I can see the latest releases of Tencent Kona JDKs, like the below,
% sdk list java | grep kona
Tencent | | 17.0.7 | kona | installed | 17.0.7-kona
| | 11.0.19 | kona | | 11.0.19-kona
| >>> | 8.0.372 | kona | installed | 8.0.372-kona
And I can install one of the above releases, for example 11.0.19,
% sdk install java 11.0.19-kona
Now, I want to install an old Tencent Kona release, say 11.0.18. How can I do that?
If you know or can derive the identifier, you can just type it. But you do not know if it is available by looking at the list, because all the out dated versions may be present, or not, because they are no longer visible. So just give 11.0.18-kona a try, maybe you are lucky. Or not.
I just tried the below command,
% sdk install java 11.0.18-kona
but it did not work as the followings,
Stop! java 11.0.18-kona is not available. Possible causes:
* 11.0.18-kona is an invalid version
* java binaries are incompatible with your platform
* java has not been released yet
Tip: see all available versions for your platform:
$ sdk list java
I suppose, before install a specific release, it should be in the output of sdk list java
at first.
Well, it should have been once.
And that is exactly the topic of this issue; I would like to be able to list ALL versions but Marco argues that that will make the list unmanageable. And I understand, but if an --invisible flag would be added and the JDK name would because of that be present on every line (unlike your example) you can use grep.
I just listed Temurin JDKs and found some older 8 releases.
% sdk list java | grep tem
Temurin | | 20.0.1 | tem | | 20.0.1-tem
| | 19.0.2 | tem | | 19.0.2-tem
| | 17.0.7 | tem | | 17.0.7-tem
| | 11.0.19 | tem | | 11.0.19-tem
| | 8.0.372 | tem | | 8.0.372-tem
| | 8.0.362 | tem | | 8.0.362-tem
| | 8.0.352 | tem | | 8.0.352-tem
| | 8.0.345 | tem | | 8.0.345-tem
How can I do that for Tencent Kona JDKs? Have I to submit a PR for that?
Was 11.0.18-kona ever released using sdkman?
@johnshajiang that is by mistake. I'll be hiding those soon when I get the time.. We should only display all latest major versions per vendor in this view.
@tbee
Was 11.0.18-kona ever released using sdkman?
No. SDKMAN just integrated Tencent Kona JDKs, exactly the latest releases. Then, I have another question: When new Tencent Kona JDKs are released, do I have to submit PRs for taking SDKMAN to integrate the new releases?
No, the releaser of Tencent Kona needs to perform REST calls.
@tbee actually no, all Java versions are fetched regularly from the Disco API that feeds us all the latest major versions per vendor.
all Java versions are fetched regularly from the Disco API that feeds us all the latest major versions per vendor.
Hmm, only the latest releases are accessible? Why not register some specific releases to SDKMAN db via some REST APIs?
actually no, all Java versions are fetched regularly from the Disco API that feeds us all the latest major versions per vendor.
I do not understand the "no". The question was about a new release. AFAIK, and as the documentation in the link shows, the releaser of a specific JDK needs to add the release to the database using REST calls. This has nothing to do with the SDKMAN client downloading available releases?
Just tried Disco API and found the below link can list all of Tencent Kona 11 releases on Linux x86_64. https://api.foojay.io/disco/v3.0/packages?package_type=jdk&distribution=kona&latest=all_of_version&version=11&operating_system=linux&architecture=x64
I suppose SDKMAN uses latest=available
instead.
Ah, and https://api.foojay.io/disco/v3.0/packages?package_type=jdk simply lists all. I can do something with that.
This kinda gives what I am looking for; curl https://api.foojay.io/disco/v3.0/packages?package_type=jdk | jq '.result[] | [.distribution_version, .distribution, .filename] | @tsv' | grep -i tencent | grep 17
I am wondering why some SDKMan URLs do not return data, for example: https://api.sdkman.io/2/candidates/maven/win/versions/all returns a lot of versions vs https://api.sdkman.io/2/candidates/java/win/versions/all returns nothing
Maven is not platform-specific, so the win
in your URL is ignored. However, Java is platform-specific and win
is an invalid platform. To see what your platform is, simply examine the ~/.sdkman/var/platform
file.
Ah, that makes sense; I found the possible platforms in the install script. But it does not really matter, because the current SDKMAN implementation in the backend will never return all available versions, as the original request of this issue describes. Maybe I should work around that by using disco's API.
I wanted to be able to list all java version by adding the "--all" option as was discussed already on the interwebs.
sdk list java --all
This would ignore the visible flag. I figured I'd give it a try, but then found out Sdkman is written in scala, and that is very out of my comfort zone. But I've analyzed what needs to be done:
That would have been all if not for that the repo is sneeky forwarding findAllVersionsByCandidatePlatform to findAllVisibleVersionsByCandidatePlatform, so:
I've even made the changes for 2, 3 and 4. Well, that is, they compile. But I'm so out of my league... I have no idea how to test it, make sure that the candidates uses the new repo. Given the amount of effort the change is, and the amount of effort it would take me to complete it... That is quite out of balance.