How to handle the various Java distributions? #364
-
|
#355 has a long discussion on the various differences between Java distributions. While our page currently tracks OpenJDK as developed by Oracle and mainly released by AdoptOpenJDK - there's many other versions going around.
This discussion is mainly to figure out how to handle the various different Java releases (ie, not the third point above - it is a much more common issue). Current best idea is to just list them all down in the same page (since it is /java after all). |
Beta Was this translation helpful? Give feedback.
Replies: 18 comments 21 replies
-
|
note Oracle released JAVA 17, and they updated JAVA license again.
We can check about new free-to-use license (Oracle No-Fee Terms and Conditions (NFTC)) here. By this, Oracle provides 3 types of JAVA from 17.
I think this topic will be one reason to separate/upgrade current JAVA page. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
I will think that we should list all java, whether who distributes or in
which license they distribute in the SAME product name. Otherwise it will
get more and more complicated.
Do we separate M$ windows product under different pages according to their
licenses ? we just adding (E) , (W) , ... or do we separate ubuntu
like xubuntu , kubuntu , lubuntu ... ?
Making each vendor or different type of licences under separate product
name will make endoflife.date looks more confusing
of course this is my 2 cents nothing more
Ömer Fadıl Usta
PGP key : 0xfd11561976b1690b
about.me/omerusta
|
Beta Was this translation helpful? Give feedback.
-
|
For comparison, we currently track Kubernetes and its various managed distributions separately:
And there are multiple other vendors offering Kubernetes (such as Ubuntu), we will likely track them separately as well. The one advantage here is that all the vendors use distinct names for their distributions (Canonical Charmed Kubernetes, RedHat OpenShift etc) so it's much more easier to distinguish. |
Beta Was this translation helpful? Give feedback.
-
|
Would it possible to get a page dedicated to K8S distros (with |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the idea of tracking Java builds separately. The way things are going in the Java world, they really seem like different builds of an open source core. Indeed, it feels like Oracle is now following the "open core" model. The different builds have differences beyond licensing too. For example, the Shenandoah garbage collector is only available from some vendors for older LTS releases:
https://wiki.openjdk.java.net/display/shenandoah/Main Organizations tend to choose Java build vendors similar to how they choose Kubernetes distributions. One might choose GKE over AKS because they run the rest of their stuff on GCP already. Similarly, an organization with a history of getting paid support might choose to get paid support from a particular Java vendor, or at least choose a free "best effort" OpenJDK build from a particular vendor, knowing that if they fail to stay caught up on their tech debt, they'll at least be ready to quickly purchase a support contract from a vendor they're already familiar with working with. Whether this is implemented as a separate page for each vendor or as multiple rows for each Java SE version is something we'd still need to decide. @usta raises a good point:
Another point I thought of in favor of listing builds separately, after reading https://medium.com/@javachampions/java-is-still-free-2-0-0-6b9aa8d6d244, is that it's been made very clear in this post from Java Champions that Oracle hands off every version of Java, including LTS versions, to the community who can then choose to maintain it. However, no vendor is obligated to provide free support. Instead, each vendor chooses how to participate by "providing updates and/or paid support". Each vendor could end up providing different types of free support 6 months after a major version is released:
Because people tend to use sites like endoflife.date to help them choose software to deploy to production based on how long free support is available, it's a good idea to break down the support options available them. An example of a vendor that appears to have already made the decision to add features without backporting them to the OpenJDK code base is Microsoft:
https://devblogs.microsoft.com/java/announcing-preview-of-microsoft-build-of-openjdk/ This means that because those features may be important to Microsoft, they may choose to offer free support for a particular Java version (via their build only) longer than other vendors may may offer free support for their builds. |
Beta Was this translation helpful? Give feedback.
-
|
Took a stab at making a page dedicated to the Temurin build from Adoptium. I modelled it after the Go page because Adoptium seems to follow a similar pattern for support for Go, where there are no fixed dates for when support ends. |
Beta Was this translation helpful? Give feedback.
-
|
In my mind something like this will be much suitable : And for the .md part thinking something like this : |
Beta Was this translation helpful? Give feedback.
-
|
I like the design idea, but I still think the text underneath itself would become too confusing to remain helpful. It would become 4-5x the length of our current pages. |
Beta Was this translation helpful? Give feedback.
-
|
I like how dense the information is. One page would be simple. But what about columns? Because the different builds have different support models, we'd need different columns for each. For example, OpenJDK follows a "supported until further notice" model:
And because Adoptium is an open source, vendor neutral project where they publish a build from the OpenJDK source code as is, that level of support would apply to the Adoptium Temurin build. We'd just need one column to indicate either Yes/No for "currently supported or not", or instead one column with "If supported, supported until at least". However, for Oracle's Oracle JDK build, they offer various levels of paid support (premier support and extended support):
We'd need two columns for this data, one for each level of support, indicating the dates Oracle has committed to offering that support. |
Beta Was this translation helpful? Give feedback.
-
|
i believe if you have a paid support you already know the eol for that
license, at least for me the importance of eol is mainly for non paid ones
…On Fri, Sep 24, 2021, 16:27 Matt Welke ***@***.***> wrote:
I like how dense the information is. One page would be simple. But what
about columns? Because the different builds have different support models,
we'd need different columns for each. For example, OpenJDK follows a
"supported until further notice" model:
[image: image]
<https://user-images.githubusercontent.com/7719209/134681837-74fb62e0-0a24-4ee0-916e-7dcdc3fb4281.png>
We'd just need one column to indicate either Yes/No for "currently
supported or not", or instead one column with "If supported, supported
until at least".
However, for Oracle's Oracle JDK build, they offer various levels of paid
support (premier support and extended support):
[image: image]
<https://user-images.githubusercontent.com/7719209/134682050-7c5bad34-2303-4c8f-8706-293c37639c14.png>
We'd need two columns for this data, one for each level of support,
indicating the dates Oracle has committed to offering that support.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#364 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA3R4QA6UHXKHQPQJRL523UDR4DHANCNFSM5DAQDX2A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
-
I was thinking the same thing. I'm sure there are paid support packages for software like Node.js too, but it's a private thing that the general public isn't interested in. The people coming to this site are probably interested in the free support dates. |
Beta Was this translation helpful? Give feedback.
-
|
What do you folks think about having a page just for OpenJDK right now, where we document the support provided by the OpenJDK maintainers? I was in touch with the Adoptium folks on Slack to try to understand this and they explained how they build from OpenJDK as is, but help connect users to the OpenJDK maintainers, reporting bugs, etc. They explained that the OpenJDK project follows a kind of "supported until further notice" model where maintainers step up to commit to maintaining old versions. In practice, this means the maintainers choose LTS versions to receive this support, because Oracle chooses which versions are designated as LTS to help the community at large focus their efforts when it comes to providing support over a long period of time:
So this means there would be a column for "Supported Until", whose value would be different depending on the status of the version in the OpenJDK project:
At this particular moment, Java 8 and Java 11 fit into that first category and Java 17 fits into that second category. Free support for Java 17 in the OpenJDK project is scheduled to end March 14th, 2021 (or perhaps at the end of that month). |
Beta Was this translation helpful? Give feedback.
-
|
OpenJDK Life Cycle and Support Policy - Red Hat Customer Portal
Red Hat seems provide their OpenJDK 17 with Long Term Support, and as Red Hat have "Upstream First" policy, |
Beta Was this translation helpful? Give feedback.
-
|
Updated
Support period of OpenJDK 17 by RedHat seems almost same as support period of OpenJDK 17 by MS
|
Beta Was this translation helpful? Give feedback.
-
|
Updated Corretto's support.
October 2029 is almost same as Oracle's Extended Support ... |
Beta Was this translation helpful? Give feedback.
-
|
To be honest the LTS thing is evil in software area for both users and
developers and also companies. If you give support for any software more
than 5 years it is insane. It just creates more and more problems for
developers than it should brings some benefits.
Think about java , if They just give support for 3 years for each version
now we wont have any problem.
…On Fri, Sep 24, 2021, 16:45 Matt Welke ***@***.***> wrote:
What do you folks think about having a page just for OpenJDK right now,
where we document the support provided by the OpenJDK maintainers? I was in
touch with the Adoptium folks on Slack to try to understand this and they
explained how they build from OpenJDK as is, but help connect users to the
OpenJDK maintainers, reporting bugs, etc.
They explained that the OpenJDK project follows a kind of "supported until
further notice" model where maintainers step up to commit to maintaining
old versions. In practice, this means the maintainers choose LTS versions
to receive this support, because Oracle chooses which versions are
designated as LTS to help the community at large focus their efforts when
it comes to providing support over a long period of time:
[image: image]
<https://user-images.githubusercontent.com/7719209/134684397-73540511-2ed7-4e87-b659-06027734da89.png>
So this means there would be a column for "Supported Until", whose value
would be different depending on the status of the version in the OpenJDK
project:
- For versions where the OpenJDK maintainers have committed to
providing long term support, it would display "Ends in at least
years/months/days ()".
- For versions where the OpenJDK maintainers have not yet committed to
providing long term support, it would display "Ends in years/months/days
()" because there would be a known date when support would end. It would be
6 months from the release date.
At this particular moment, Java 8 and Java 11 fit into that first category
and Java 17 fits into that second category. Free support for Java 17 in the
OpenJDK project is scheduled to end March 14th, 2021 (or perhaps at the end
of that month).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#364 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA3R4UQ7XBRB7SMWOD26MDUDR6HZANCNFSM5DAQDX2A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
-
|
The recommended way to use Java is actually now to use the latest version and upgrade every 6 months. Ron Pressler (@pron), who works at Oracle and is the current Project Loom lead, often expresses this when he contributes to discussions about Java versions on discussion platforms. So Oracle now wants the Java community to upgrade every 6 months. But as for whether the community will follow these instructions, only time will tell. Two prominent Java open source projects I follow, Apache Beam and Apache OpenWhisk, are still stuck on Java 8 right now. Even though some of us may find the idea of LTS bad and would prefer the community upgrade often, we should meet the community where they're at when it comes to putting this information online. We do them no service by hiding it from them. They'll try to find that information somewhere else. We could even add a note at the bottom saying "The OpenJDK project/Oracle suggests you run the latest Java version in production at all times." |
Beta Was this translation helpful? Give feedback.
-
|
For a lot of hard-to-budge clients this is crazy-talk. I normally feel like Sisyphus at work just attempting to get our client-support engineers to cease-and-desist using the JDK 1.7 runtime (I think they may finally comprehend that they can continue to build with 1.7 if they must, but run on 1.8). If you watch surveys like the one IntelliJ does yearly, there is still about 1/2 of the Java community using 1.8, while the other half has moved to 1.11 (it has taken years). Presuming that they'll move every 6 months, especially with one-off custom applications for clients is fairly nuts. Consider the fact that [years ago] when I did work for the DoD, it could take 2-3 years just to get a new library (i.e. JDK 17 let's say) approved for internal use. |
Beta Was this translation helpful? Give feedback.
-
|
you misunderstood me , i am not talking about hiding data/date. i am just angry
to companies who just increase eol dates just to earn more , which goes
like a race that if company a says my eol is 5 years other one says mine is
7 other says 10 , then in bussiness world which i am talking about the
decision makers (which doesnt know anything about how software evolves)
keep their system to current version.
It blocks almost all projects get better because they just try to keep
support older active lts versions.
…On Fri, Sep 24, 2021, 17:06 Matt Welke ***@***.***> wrote:
The recommended way to use Java is actually now to use the latest version
and upgrade every 6 months. Ron Pressler, who works at Oracle and is the
current Project Loom lead, often expresses this when he contributes to
discussions about Java versions on discussion platforms.
So Oracle now wants the Java community to upgrade every 6 months. But as
for whether the community will follow these instructions, only time will
tell. Two prominent Java open source projects I follow, Apache Beam and
Apache OpenWhisk, are still stuck on Java 8 right now.
Even though some of us may find the idea of LTS bad and would prefer the
community upgrade often, we should meet the community where they're at when
it comes to putting this information online. We do them no harm by hiding
it from them. We could even add a note at the bottom saying "The OpenJDK
project/Oracle suggests you run the latest Java version in production at
all times."
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#364 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA3R4USTASPNOFJ67RQJZDUDSAVNANCNFSM5DAQDX2A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
-
|
This is just an idea, but how about layerd tree
JAVA/OpenJDK support has many changes recently. // And, layerd tree may be useful for other usage. |
Beta Was this translation helpful? Give feedback.
-
|
This looks good. |
Beta Was this translation helpful? Give feedback.
-
|
this looks good , but all in one page for a summer also be good if the
person just clicks java
…On Fri, Sep 24, 2021, 19:28 witchcraze ***@***.***> wrote:
This is just an idea, but how about layerd tree
[image: image]
<https://user-images.githubusercontent.com/67056980/134709224-e1cf6430-fcc4-423a-b402-9416fa57bceb.png>
JAVA/OpenJDK support has many changes recently.
I think we can't continue to summarize many vendor/community support into
one table.
// And, layerd tree may be useful for other usage.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#364 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA3R4U6DOUOPRAP2UXRI5TUDSRKDANCNFSM5DAQDX2A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
-
|
http://whichjdk.com/ documents many more Java vendors. |
Beta Was this translation helpful? Give feedback.
-
|
Seems like the end-of-life for some of the recent LTS versions of Java should perhaps just be marked with a combination of whatever date Oracle gives + vendor dependent for the OpenJDK and maybe provide a list of the popular vendor sites like Adoptium. |
Beta Was this translation helpful? Give feedback.
-
Sorry for coming late to this discussion, I've discovered this topic with the Coretto issue. If it can help, sdk list java================================================================================
Available Java Versions for Linux 64bit
================================================================================
Vendor | Use | Version | Dist | Status | Identifier
--------------------------------------------------------------------------------
Corretto | | 19.0.2 | amzn | | 19.0.2-amzn
| | 19.0.1 | amzn | | 19.0.1-amzn
| | 17.0.6 | amzn | | 17.0.6-amzn
| | 17.0.5 | amzn | | 17.0.5-amzn
| | 11.0.18 | amzn | | 11.0.18-amzn
| | 11.0.17 | amzn | | 11.0.17-amzn
| | 8.0.362 | amzn | | 8.0.362-amzn
| | 8.0.352 | amzn | | 8.0.352-amzn
Dragonwell | | 17.0.5 | albba | | 17.0.5-albba
| | 17.0.4 | albba | | 17.0.4-albba
| | 11.0.17 | albba | | 11.0.17-albba
| | 11.0.16 | albba | | 11.0.16-albba
| | 8.0.352 | albba | | 8.0.352-albba
| | 8.0.345 | albba | | 8.0.345-albba
Gluon | | 22.1.0.1.r17 | gln | | 22.1.0.1.r17-gln
| | 22.1.0.1.r11 | gln | | 22.1.0.1.r11-gln
GraalVM | | 22.3.r19 | grl | | 22.3.r19-grl
| | 22.3.r17 | grl | | 22.3.r17-grl
| | 22.3.r11 | grl | | 22.3.r11-grl
| | 22.2.r17 | grl | | 22.2.r17-grl
| | 22.2.r11 | grl | | 22.2.r11-grl
| | 22.1.0.r17 | grl | | 22.1.0.r17-grl
| | 22.1.0.r11 | grl | | 22.1.0.r11-grl
| | 22.0.0.2.r17 | grl | | 22.0.0.2.r17-grl
| | 22.0.0.2.r11 | grl | | 22.0.0.2.r11-grl
| | 21.3.3.r17 | grl | | 21.3.3.r17-grl
| | 21.3.3.r11 | grl | | 21.3.3.r11-grl
| | 21.3.3.1.r17 | grl | | 21.3.3.1.r17-grl
| | 21.3.3.1.r11 | grl | | 21.3.3.1.r11-grl
| | 21.3.2.r17 | grl | | 21.3.2.r17-grl
| | 21.3.2.r11 | grl | | 21.3.2.r11-grl
| | 21.3.1.r8 | grl | | 21.3.1.r8-grl
| | 21.2.0.r8 | grl | | 21.2.0.r8-grl
| | 21.1.0.r8 | grl | | 21.1.0.r8-grl
| | 20.3.6.r11 | grl | | 20.3.6.r11-grl
| | 20.3.3.r8 | grl | | 20.3.3.r8-grl
| | 20.3.2.r8 | grl | | 20.3.2.r8-grl
| | 19.3.6.r11 | grl | | 19.3.6.r11-grl
| | 19.3.6.r8 | grl | | 19.3.6.r8-grl
Java.net | | 21.ea.6 | open | | 21.ea.6-open
| | 21.ea.5 | open | | 21.ea.5-open
| | 21.ea.4 | open | | 21.ea.4-open
| | 20.ea.32 | open | | 20.ea.32-open
| | 20.ea.31 | open | | 20.ea.31-open
| | 20.ea.30 | open | | 20.ea.30-open
| | 19.ea.1.pma | open | | 19.ea.1.pma-open
| | 19.0.2 | open | | 19.0.2-open
| | 19.0.1 | open | | 19.0.1-open
| | 11.0.12 | open | | 11.0.12-open
| | 11.0.2 | open | | 11.0.2-open
| | 8.0.302 | open | | 8.0.302-open
| | 8.0.282 | open | | 8.0.282-open
| | 8.0.265 | open | installed | 8.0.265-open
Liberica | | 19.0.2.fx | librca | | 19.0.2.fx-librca
| | 19.0.2 | librca | | 19.0.2-librca
| | 19.0.1.fx | librca | | 19.0.1.fx-librca
| | 19.0.1 | librca | | 19.0.1-librca
| | 17.0.6.fx | librca | | 17.0.6.fx-librca
| | 17.0.6 | librca | | 17.0.6-librca
| | 17.0.5.fx | librca | | 17.0.5.fx-librca
| | 17.0.5 | librca | | 17.0.5-librca
| | 11.0.18.fx | librca | | 11.0.18.fx-librca
| | 11.0.18 | librca | | 11.0.18-librca
| | 11.0.18 | librca | | 11.0.18-librca
| | 11.0.17.fx | librca | | 11.0.17.fx-librca
| | 11.0.17 | librca | | 11.0.17-librca
| | 8.0.362.fx | librca | | 8.0.362.fx-librca
| | 8.0.362 | librca | | 8.0.362-librca
| | 8.0.352.fx | librca | | 8.0.352.fx-librca
| | 8.0.352 | librca | | 8.0.352-librca
| | 8.0.332.fx | librca | | 8.0.332.fx-librca
Liberica NIK | | 22.3.r17 | nik | | 22.3.r17-nik
| | 22.3.r11 | nik | | 22.3.r11-nik
| | 22.2.r17 | nik | | 22.2.r17-nik
| | 22.2.r11 | nik | | 22.2.r11-nik
| | 22.1.r17 | nik | | 22.1.r17-nik
| | 22.1.r11 | nik | | 22.1.r11-nik
| | 22.0.0.2.r17 | nik | | 22.0.0.2.r17-nik
| | 22.0.0.2.r11 | nik | | 22.0.0.2.r11-nik
| | 21.3.3.r17 | nik | | 21.3.3.r17-nik
| | 21.3.3.r11 | nik | | 21.3.3.r11-nik
| | 21.3.3.1.r17 | nik | | 21.3.3.1.r17-nik
| | 21.3.3.1.r11 | nik | | 21.3.3.1.r11-nik
| | 21.3.2.r17 | nik | | 21.3.2.r17-nik
| | 21.3.2.r11 | nik | | 21.3.2.r11-nik
| | 21.2 | nik | | 21.2-nik
| | 21.1 | nik | | 21.1-nik
| | 21.0.0.2.r11 | nik | | 21.0.0.2.r11-nik
| | 21.0.0.2 | nik | | 21.0.0.2-nik
Mandrel | | 22.3.0.1.r17 | mandrel | | 22.3.0.1.r17-mandrel
| | 22.2.r17 | mandrel | | 22.2.r17-mandrel
| | 22.2.r11 | mandrel | | 22.2.r11-mandrel
| | 22.1.0.0.r17 | mandrel | | 22.1.0.0.r17-mandrel
| | 22.1.0.0.r11 | mandrel | | 22.1.0.0.r11-mandrel
| | 22.0.0.2.r17 | mandrel | | 22.0.0.2.r17-mandrel
| | 22.0.0.2.r11 | mandrel | | 22.0.0.2.r11-mandrel
| | 21.3.4.r17 | mandrel | | 21.3.4.r17-mandrel
| | 21.3.4.r11 | mandrel | | 21.3.4.r11-mandrel
| | 21.3.3.r17 | mandrel | | 21.3.3.r17-mandrel
| | 21.3.3.r11 | mandrel | | 21.3.3.r11-mandrel
| | 21.3.2.0.r17 | mandrel | | 21.3.2.0.r17-mandrel
| | 21.3.2.0.r11 | mandrel | | 21.3.2.0.r11-mandrel
| | 21.3.1.1.r17 | mandrel | | 21.3.1.1.r17-mandrel
| | 21.3.1.1.r11 | mandrel | | 21.3.1.1.r11-mandrel
| | 21.3.1.0.r17 | mandrel | | 21.3.1.0.r17-mandrel
| | 21.3.1.0.r11 | mandrel | | 21.3.1.0.r11-mandrel
| | 21.3.0.0 | mandrel | | 21.3.0.0-mandrel
| | 21.2.0.2 | mandrel | | 21.2.0.2-mandrel
| | 20.3.3.0 | mandrel | | 20.3.3.0-mandrel
Microsoft | | 17.0.5 | ms | | 17.0.5-ms
| | 11.0.17 | ms | | 11.0.17-ms
Oracle | | 19.0.2 | oracle | | 19.0.2-oracle
| | 19.0.1 | oracle | | 19.0.1-oracle
| | 17.0.6 | oracle | | 17.0.6-oracle
| | 17.0.5 | oracle | | 17.0.5-oracle
SapMachine | | 19.0.2 | sapmchn | | 19.0.2-sapmchn
| | 19.0.1 | sapmchn | | 19.0.1-sapmchn
| | 17.0.6 | sapmchn | | 17.0.6-sapmchn
| | 17.0.5 | sapmchn | | 17.0.5-sapmchn
| | 11.0.18 | sapmchn | | 11.0.18-sapmchn
| | 11.0.17 | sapmchn | | 11.0.17-sapmchn
Semeru | | 18.0.2 | sem | | 18.0.2-sem
| | 17.0.5 | sem | | 17.0.5-sem
| | 17.0.4.1 | sem | | 17.0.4.1-sem
| | 11.0.17 | sem | | 11.0.17-sem
| | 11.0.16.1 | sem | | 11.0.16.1-sem
| | 8.0.352 | sem | | 8.0.352-sem
| | 8.0.345 | sem | | 8.0.345-sem
Temurin | | 19.0.1 | tem | | 19.0.1-tem
| | 17.0.6 | tem | | 17.0.6-tem
| >>> | 17.0.5 | tem | installed | 17.0.5-tem
| | 8.0.352 | tem | | 8.0.352-tem
| | 8.0.345 | tem | | 8.0.345-tem
Trava | | 11.0.15 | trava | | 11.0.15-trava
| | 11.0.9 | trava | | 11.0.9-trava
| | 8.0.282 | trava | | 8.0.282-trava
| | 8.0.232 | trava | | 8.0.232-trava
Zulu | | 19.0.2 | zulu | | 19.0.2-zulu
| | 19.0.1 | zulu | | 19.0.1-zulu
| | 19.0.1.fx | zulu | | 19.0.1.fx-zulu
| | 17.0.6 | zulu | | 17.0.6-zulu
| | 17.0.5 | zulu | | 17.0.5-zulu
| | 17.0.5.fx | zulu | | 17.0.5.fx-zulu
| | 11.0.18 | zulu | | 11.0.18-zulu
| | 11.0.17 | zulu | | 11.0.17-zulu
| | 11.0.17.fx | zulu | | 11.0.17.fx-zulu
| | 8.0.362 | zulu | | 8.0.362-zulu
| | 8.0.352 | zulu | | 8.0.352-zulu
| | 8.0.352.fx | zulu | | 8.0.352.fx-zulu
| | 7.0.352 | zulu | | 7.0.352-zulu
| | 6.0.119 | zulu | | 6.0.119-zulu
💡 I guess that with a proper tagging we could so something efficient 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
... some automation could be made thanks to foojay API 🔖 Foojay API on github.com At the moment the following distributions are supported by the API: :
|
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately no, because the API don't expose the release date which is, at least currently, mandatory. |
Beta Was this translation helpful? Give feedback.
-
|
Just went through all this thread, here are the proposed solutions so far :
I am not in favor of the first solution. I agree that would be great to have a summary of all versions / vendors, but:
The second solution, i.e. the layered tree, would be the best IMHO :
The third solution is not ideal, but it is the only one that can be implemented today without modifying anything in endoflife.date. So I would choose this solution for the time being, while researching how to implement the layered tree in endoflife.date. I don't think this is an issue, because child page in the layered tree are "classic" endoflife product pages. So could we agree that each Java distribution must be documented on its own page? This way we could at least document end of life for requested products such as #2334. |
Beta Was this translation helpful? Give feedback.
-
|
+1 to the recommended approach (Option 3 today, working towards Option 2). I also like the idea of having pages for prominent frameworks in the Java ecosystem such as Spring Boot. That precedent has already been set. We have https://endoflife.date/ruby and we have https://endoflife.date/rails. Having that "Java" intro page, eventually displayed in a nice tree structure on the page, will be a great place to list Java ecosystem things tracked on the site such as Spring Boot. |
Beta Was this translation helpful? Give feedback.
-
I agree on not adding Debian JDK but not for the same reason. Certification shouldn't necessarily be a bar for us to list a project, imo (We focus on Being Helpful, and that includes listing uncertified projects that are still used). However, we shouldn't add it still, because we don't list separate EOLs for any other debian variant packages. Debian Buster still supports Ansible 2.7 for eg), but we don't have a page for it separately. Users are expected to check the Debian page in such cases already (And ideally our scanning tooling will take care of such things). A minor note on the difference between the ruby and java page being discussed here - It's probably better to use a separate tag like |
Beta Was this translation helpful? Give feedback.
-
|
💯 👌 |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to list AdoptOpenJDK as well, considering there might be projects still using it that haven't upgraded to Adoptium . Providing clear information on it would be helpful to such users. |
Beta Was this translation helpful? Give feedback.
-
|
Filed a PR for RedHat OpenJDK: #3249 That leaves us with AdoptOpenJDK, and the splitting of openjdk page. |
Beta Was this translation helpful? Give feedback.
-
Sure 👏 |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, this is awesome 👏 |
Beta Was this translation helpful? Give feedback.
Just went through all this thread, here are the proposed solutions so far :
I am not in favor of the first solution. I agree that would be great to have a summary of all versions / vendors, but:
product.htmltemplate, the automation).