whichjdk / whichjdk.com Goto Github PK

https://github.com/ojdkbuild/ojdkbuild

They discontinued recently.

Other than their readme, also see: https://github.com/ojdkbuild/ojdkbuild/wiki/Motivation

(I'm a total noob if you ask me anything about Java ecosystem.) What is relationship between OpenJDK and IcedTea? I always wasn't sure should I install in my linux something similar to "java-jdk" or "icedtea".

It will be a great addition to mention which vendors has native support for Apple Silicon.

✅ Recommendation: Use Adoptium Eclipse Temurin 21 and ensure that your local version matches the CI and production version.

Well, version 21 is not yet available. According to their website, it's expected to come out this month but today it's not possible to download.
So how can this version already be recommended?

If you are recommending Quarkus over JakartaEE then Micronaut is a valid recommendation also.

Every three years, the September release will be a Long-Term-Support (LTS) release, which gets updates for at least three years.

Oracle proposed a shorter LTS release cycle from three years to two years in 2021. So a LTS release will occur every four versions instead of every six - JDK 21 instead of JDK 23.

https://blogs.oracle.com/java/post/moving-the-jdk-to-a-two-year-lts-cadence

https://mreinhold.org/blog/forward-even-faster

I would be nice to mention this on the page.

When viewing the https://whichjdk.com/, I can see that an ⚠️-emoji is normally used for recommendations that depend on the use-case.

However, IBM Semeru Runtime uses a ⛔️-emoji even though the recommendation states

Use IBM Semeru Runtime only if you know that you need the OpenJ9 Virtual Machine.

I think this recommendation for IBM Semeru Runtime should use the emoji ⚠️.

Hi, nice list, we are looking at implementing jre and jdk versions in our cicd pipelines and our application base image policy. I found your site veryhelpful, but i am wondering why temurin is being advised. Currently our team has selected debian jdk and jre, because debian is a well respected provider, and provides steady security updates. i can fully understand that readoning, so my question is, how does the debian jdk stack up to the temurin jdk and shy should we favour one over the other? Would you recommend switching to temurin, and if so, why? forgive me if this information is somewhere on the site, i could not find it using a search for debian.

which i use on windows, includes server, how about microsoft builds?

Hey - Your site is the best I've found for the info we need to choose/discuss JDK Vendors... now there's a release of openjdk by redhat and I'm having trouble discerning licensing as compared to Oracle's OpenJDK License. Relevant Links:

https://access.redhat.com/articles/1299013?extIdCarryOver=true&sc_cid=701f2000001OH7JAAW

https://developers.redhat.com/oraclejdkalternative

The RPM package used by 'dnf install java-17-openjdk' seems like it would be pulling oracle - but instead I see that it has up to date patching provided by redhat:

https://src.fedoraproject.org/rpms/java-17-openjdk/blob/rawhide/f/java-17-openjdk.spec#_2380

I'm not sure how to evaluate pros/cons of this as compared to Temurin which is our current choice.

Thanks!

Hi Jochen,

> The JRE is a stripped down version of the JRE, and is smaller in terms of Megabytes.
                                            ^^^

it looks here it should be JDK instead if JRE ?

The links to Amazon Corretto link to https://aws.amazon.com/de/corretto/ instead of https://aws.amazon.com/en/corretto/, so they are in German instead of English. Both the Website and Releases links are in German, but the Docker Images link and images in the part describing Amazon Corretto are already in English so that is fine. Also there is a link to https://www.oracle.com/de/downloads/licenses/binary-code-license.html for the Oracle Binary Code Agreement in German instead of the English link https://www.oracle.com/downloads/licenses/binary-code-license.html

Anyway, it would be best to replace these with the English links. So that above part of this issue is for German-language websites being linked from both English and Korean versions of your site, something that should be fixed.

The rest of this post concerns the Korean version of your site using the same exact links as the English version.

The Korean version of the site uses the same links as the English version of the site. Some of these can be replaced with Korean-language links.

The official OpenJDK website, wcsp website, Adoptium Eclipse Temurin website, Docker website, AdoptOpenJDK website, Bellsoft Liberica website, IBM developer website, Eclipse website, Github website, Alibaba Dragonwell website, SapMachine website, Red Hat OpenJDK website, GraalVM, SDKMAN website, Spring Boot website, Micronaut website, and Quarkus website all either do not have Korean versions or use the same URLs for other languages, so there is no need for other links for other languages.

But the Oracle and Amazon websites have full Korean versions while the Azul Zulu / Azul Zing website and Microsoft website have only some pages available in Korean but not others. So the 4 websites that have at least some Korean webpages with different URLs are Oracle, Amazon, Azul, and Microsoft. The rest of the websites linked do not need anything done for Korean users.

So replace https://www.oracle.com/java/technologies/java-se-support-roadmap.html with https://www.oracle.com/kr/java/technologies/java-se-support-roadmap.html, https://www.oracle.com/java/ with https://www.oracle.com/kr/java/, https://www.oracle.com/java/technologies/downloads/archive/ with https://www.oracle.com/kr/java/technologies/downloads/archive/, https://www.oracle.com/de/downloads/licenses/binary-code-license.html with https://www.oracle.com/kr/downloads/licenses/binary-code-license.html, https://www.oracle.com/downloads/licenses/javase-license1.html with https://www.oracle.com/kr/downloads/licenses/javase-license1.html, https://www.oracle.com/downloads/licenses/no-fee-license.html with https://www.oracle.com/kr/downloads/licenses/no-fee-license.html on the Korean version of the page. The pattern for all of these oracle.com links is /kr/ after oracle.com for the Korean version of the page, while you leave a language code out for the English version of the page.

For Azul Zulu / Azul Zing, replace https://www.azul.com/ with https://www.azul.com/ko/ for the main webpage in Korean, but keep the webpages https://www.azul.com/downloads/?package=jdk#download-openjdk and https://www.azul.com/products/prime-roadmap/ the same as they are only available in English.

For Amazon Corretto, replace https://aws.amazon.com/de/corretto/ with https://aws.amazon.com/ko/corretto/ and https://aws.amazon.com/corretto/faqs/ with https://aws.amazon.com/ko/corretto/faqs/ and https://aws.amazon.com/blogs/opensource/introducing-amazon-corretto-crypto-provider-accp/ with https://aws.amazon.com/ko/blogs/opensource/introducing-amazon-corretto-crypto-provider-accp/ for the Korean webpages. The pattern for all of these aws.amazon.com links is /ko/ after aws.amazon.com for the Korean version of the page, while you leave a language code out for the English version of the page.

For Microsoft Build of OpenJDK, keep https://www.microsoft.com/openjdk the same because the main www.microsoft.com website uses the same URLs for all languages. But replace https://docs.microsoft.com/en-us/java/openjdk/download with https://learn.microsoft.com/ko-kr/java/openjdk/download for the Korean webpage on docs.microsoft.com.

That is everything, as far as showing people links in the correct language whenever possible. You do not need to replace any of the text displayed on the webpage in either English or Korean as far as this issue is concerned, only URLs for links that it links to. So you do not need to know any Korean to replace those URLs, you can leave the text of the page unchanged and just replace certain URLs, and note for the future that Oracle, Azul, Amazon, and Microsoft have different URLs on their webpages depending on the language, while the other websites you link to either do not, or do not include Korean as a language option.

One of the Azul entries says: "Apart from that, the OpenJDK contains the low pause time GCs Shenandoah and ZGC that may be an alternative."

But the Red Hat entry doesn't mention Shenandoah, despite the fact that they developed it and ship it.

Thanks for this useful list.

Hello,
I need some help.
I tried many JDKs (Termurin JDKs, RedHat JDKs and Microsoft JDKs) but none of them works...
I'm trying to run Java on a shared hosting with terminal access, but no root access.
Portable version of softwares can be used without root, that what I wanted to do.
But, any version I run has issues. Here are the common messages gaven:

• Segmentation fault (core dumped)
• No such file or directory (even if the file appears in ls -l, it seems like a library is missing so it shows this)

The server seems to be running on RHEL8 x86_64. You probably do not know the host I use, it's called o2switch.
It's a French hosting service, since I'm French, I'm using it, even if its not a VPS, I have terminal access, lots of "computer power" (like 48Gb RAM, "Unlimited" NVMe SSD, etc...). I asked them for help 2 times, because the error was not only for Java but for every prebuilt binaries I downloaded (I tried ffmpeg, p7zip and they gave the same error, but this time only Segmentation fault (core dumped), also it seems that when building the software from source on the server it works, I tested with p7zip, but since OpenJDK has lots of requirements and almost nothing is installed on the server, I'm asking for help first).
They said (I translated from French to English for you): "The binaries are not correct." about ffmpeg (because I built it manually) and specifically for Java: "Java is not available on our hosting service." (I actually asked for Java access).
Any ideas why it does not works ?

The members of the Vulnerability Group, which includes all well-known JDK vendors except Adoptium, get access to security patches before they are pushed to the open repo to allow them time to produce builds.

https://www.reddit.com/r/java/comments/u8p0ce/cve202221449/

https://whichjdk.com/ is currently dead, and the wichjdk.com DNS entry does not resolve anymore:

$ dig whichjdk.com

; <<>> DiG 9.16.42-Debian <<>> whichjdk.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31123
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;whichjdk.com.			IN	A

;; Query time: 312 msec
;; SERVER: fd0f:ee:b0::1#53(fd0f:ee:b0::1)
;; WHEN: Sun Aug 27 18:39:12 CEST 2023
;; MSG SIZE  rcvd: 41

Is whichjdk.com dead ?

(Shameless plug alert)

Hi,

I've made an Ansible Galaxy role for installing Java:

https://galaxy.ansible.com/bviktor/java
https://github.com/noobient/ansible-galaxy-java

Which provides an (I think) pretty convenient way to install various versions of Java in Ansible playbooks. You just specify flavor (you call them distros), and LTS version number, and that's it.

- include_role:
    name: bviktor.java
  vars:
    version: 11
    flavor: temurin

It's not necessarily for the average user, it's more of a deployment thing, it's obviously up to you to decide, you might find it worthwhile to mention on your site.

Thanks.

Hi, thanks for making this site, it really helps sort through the options!

Might I suggest enforcing HTTPS for the site? It should be just a few clicks and will reduce risk a little bit for people visiting the site who will then be clicking links to download JDKs.

What a lovely resource!

Some of the recommendations are without written out reasoning or rationale. For example Alibaba Dragonwell has a "red stop sign" with "Do not use unless you are forced"....and Red Hat OpenJDK has a "yellow warning" with "Use only if you are running on RHEL".

I would probably agree with those recommendations, but have only a really fuzzy thought process behind that. Alibaba...well I have never heard anyone using it, and it's Chinese, so it sounds a bit iffy. Red Hat....well, don't know much about that, to be honest I have no idea if it's better or worse option that e.g. Corretto.

I can only guess if you just went through a similar fuzzy thought process or if you had some specific points about Alibaba, Red Hat, Microsoft, etc that mean those should be avoided. It would be nice to see what the basis for not-recommending some options were, if I am sometimes in a position where I need to consider Microsoft Build of OpenJDK, Alibaba, Red Hat OpenJDK, etc. Even if reason is simply "there are more established options out there" or "I don't know enough of this one", it can be useful to know see that that's the basis of the recommendation.

Hi there!

I found this website and I find it pretty good at describing what options are there for JDK/JRE builds. However, I've found out that it (and some other placed) mention RedHat builds, but it doesn't mention Canonical builds in Ubuntu.

In Ubuntu 20.04 LTS and Ubuntu 21.10, there are openjdk-11-... packages in main section, meaning that they are supported by the Canonical. However, there are also packages for OpenJDK 8, 16, 17 and 18, but they are in the universe section (meaning they are not supported by Canonical).

I don't know the details but probably we can research those and add to the website. I don't know if I should recommend those, but if one uses Ubuntu in production using packages from the official archive probably is a default strategy.

Just Feedback: I love that SDKMan makes it very easy to install java but I think jenv deserves recognition here.

SDKMan unfortunately has a very wide scope which mean it provides easy ways to do things that are actually harmful (installing gradle to the path). jenv's setup is heaps uglier brew install corretto17 && jenv add /Library/Java/JavaVirtualMachines/amazon-corretto-17.jdk/Contents/Home/ [MacOS], but in some contexts (I'm thinking about my work in a large company) that's outweighed by jenv not being a general purpose tool (see tfenv, nvm etc.).

asdf is another contender in the space but I don't have much detail as we had trouble with it conflicting with NVM and not supporting legacy versions we needed.

Anyways in general - list is great! More reasoning/why nots in the version management space would make it even better.
Hit me up if you would like input on any changes this prompts, or want me to draft something.