-
-
Save marc0der/68e1d71d7542e5cf548f21ba9692afe0 to your computer and use it in GitHub Desktop.
================================================================================ | |
Available Java Versions | |
================================================================================ | |
Vendor | Current | Version | Status | Identifier | |
-------------------------------------------------------------------------------- | |
AdoptOpenJDK | | 12.0.1.j9 | available | 12.0.1.j9-adpt | |
| >>> | 12.0.1.hs | available | 12.0.1.hs-adpt | |
| | 11.0.3.j9 | installed | 11.0.3.j9-adpt | |
| | 11.0.3.hs | available | 11.0.3.hs-adpt | |
| | 8.0.212 | available | 8.0.212-adpt | |
| | 8.0.212 | available | 8.0.212-adpt | |
Amazon | | 11.0.2 | outdated/local | 11.0.2-amzn | |
| | 8.0.192 | installed | 8.0.192-amzn | |
GraalVM | | 19.0.0 | installed | 19.0.0-grl | |
| | 1.0.0-rc-16 | installed | 1.0.0-rc-16-grl | |
| | 1.0.0-rc-15 | outdated/local | 1.0.0-rc-15-grl | |
OpenJDK | | 13.ea.20 | available | 13.ea.20-open | |
| | 12.0.1 | available | 12.0.1-open | |
| | 11.0.2 | available | 11.0.2-open | |
| | 10.0.2 | available | 10.0.2-open | |
| | 9.0.4 | available | 9.0.4-open | |
Oracle | | 8.0.201 | outdated/local | 8.0.201-oracle | |
Zulu | | 12.0.1 | installed | 12.0.1-zulu | |
| | 12.0.0 | outdated/local | 12.0.0-zulu | |
| | 11.0.3 | available | 11.0.3-zulu | |
| | 10.0.2 | available | 10.0.2-zulu | |
| | 9.0.7 | available | 9.0.7-zulu | |
| | 9.0.7 | available | 9.0.7-zulu | |
| | 8.0.212 | available | 8.0.212-zulu | |
| | 7.0.222 | available | 7.0.222-zulu | |
| | 6.0.119 | available | 6.0.119-zulu | |
================================================================================ | |
Use the Identifier for installation: | |
$ sdk install java 11.0.3.hs-adpt | |
================================================================================ |
I hate to be that guy, but I feel this is going in the wrong direction. At least for my use of SDKMAN, it wouldn't really help.
What I had hoped to see were different "releases" for the major versions, so that I can do sdk use java 8
or sdk default java 12
. Updates shouldn't be offered between major versions (e.g. 11.0.3-zulu
shouldn't be offered as an update to 8.0.201-oracle
).
Within a release, I agree with @vpavic in sdkman/sdkman-cli#696 – an update should always keep the same vendor (e.g. 11.0.3-zulu
shouldn't be offered as an update to 11.0.0-open
).
Essentially, I want the vendor to be implicit (i.e. "the one I installed").
The design here instead makes the different vendors more explicit.
@hho No worries for being that guy 😄
I totally agree with what you are saying, but also very firmly believe in doing everything in small iterations. I never do big bang changes. They are dangerous and irresponsible.
The feature you are describing here is a completely separate matter. Tracking major versions has nothing to do with custom enhancements for Java and will be addressed as a separate piece of work. Tracking major versions are not specific to Java, but will be used for all SDKs.
People actually are interested in seeing the Java releases grouped by vendor, and this will lead us to later track not only the major version but also by vendor. In other words, if you want to track the latest major version 8 of Corretto, you can do so.
I want to keep the backend work at minimal for this set of changes, and want to start drawing some distinction between JDKs and SDKs from here on; the JDK is very different and should be treated so.
TLDR, this is not about major version tracking, it is about treating Java differently.
Also forgot to mention that the next step after this will lead us down the road to start issuing commands like:
$ sdk i java zulu 11.0.3
$ sdk i java zulu
And then later we can introduce:
$ sdk i java zulu 11
This is a first mock-up of what the new Java list view could look like. Please feel free to leave comments!
Things to consider:
After we've completed refining this, it will be implemented in the sdkman-candidates service as a template.