19 ms·

Which version of JDK should I use?

329 points by aiobe 5y ago

modeless 5y ago
What a great site! I have often wondered about these things but I'm not a Java guy so I never investigated for myself. I've never heard of Adoptium before but it sounds like the right choice.
bombcar 5y ago
No mention of GraalVM - https://www.graalvm.org https://www.graalvm.org - perhaps because it's Oracle?
- kaba0 5y ago
  Graal is (also) a goddamn Oracle project, smh… The reason it doesn’t mention it is because it is a useless website.
nlitened 5y ago
Is there a way to apt-get the new JDK 17 as a package on Ubuntu, instead of piping a shell script from curl or unzipping a tar? Does anybody use package managers on Linux anymore?
- needusername 5y ago
  Getting Java through apt-get gives you more or less the worst quality builds https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009330.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/0... You get mystery bits that haven't been put through the TCK.
  - nlitened 5y ago
    I think a custom package repository could be a proper solution then. This way one would get version upgrades for free. Much better than installing (curl-piping) yet another package management tool `sdkman` with a new syntax. Though, I might be missing some important details, and I would love to understand it better. Edit: a sibling comment suggested that now there's a package repository for that, and indeed there is.
- severino 5y ago
  Last time I checked, at least in Ubuntu 20.04, there was already a package for OpenJDK 17, so I think that's the straightforward and recommended way to get Java 17 in Ubuntu.
  - nlitened 5y ago
    Wow, you're actually right — I wasn't able to find it before (maybe Java 17 was too new back then). If anybody's interested: sudo add-apt-repository ppa:linuxuprising/java sudo apt-get update sudo apt-get install oracle-java17-installer oracle-java17-set-default
    - severino 5y ago
      Yes, I checked some weeks ago and v.16 was the last one, so I guess it was too soon. However, you don't need a special repo for getting OpenJDK 17. Yours is for getting Oracle JDK 17, right?
- Freak_NL 5y ago
  I don't like the 'curl -s "https://XXX https://XXX" | bash' approach much either, but I've given up trying to work around it. With SDKMan switching between JDKs is painless, despite the install method of SDKMan itself being one of those. But it's not just Java. To build our frontend webapp I need NodeJS, and there too some specific version depending on the version of the webapp or just because we've updated. I'd love to be able to just apt install all of this, but the downsides are just too many.
  - KronisLV 5y ago
    Personally, i just use containers to manage business applications - which often need a very particular runtime that's tested, verified and signed off on for maximum stability and predictable deployments. On the other hand, i only use standard packages through apt/yum/apk/whatever for server software, a distinction that's lost too often in my opinion. Everything that the server needs to operate should have automatic (at least security) updates enabled and ideally the configuration should be fully automated through Ansible with something like GitOps and read only access through SSH (with fallback account with write access for special cases) for maximum auditability and being sure that this is less likely to happen: https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/ https://dougseven.com/2014/04/17/knightmare-a-devops-caution... Furthermore, the servers themselves can be viewed as pretty much disposable at that point. A VM gets corrupted? Wipe it, create a new one, run Ansible against it to set up the environment, then just give the node a label in your container orchestration platform of choice and watch as your business software is automatically provisioned on the node, bringing the total capacity of your cluster up once again. For personal devices with no important credentials, or development boxes which are similarly unimportant, piping random stuff and trying to work around the problems with multiple SDKs is more permissible, however. Seeing as PHP, Ruby, Go, Java, .NET, Python and other technologies aren't always pleasant to work with if you have different projects that need different environments, as humorously pointed out here: https://xkcd.com/1987/ https://xkcd.com/1987/ Containers aren't always comfortable to use for local development (especially with OSes like Windows locally, without WSL2, due to problems with bind mounts but perhaps are for components like DBs, Redis, MongoDB etc.), but in certain dev boxes they are also viable, thus making development even easier.
karmakaze 5y ago
This page should definitely have a "end of free public updates" column as is shown on the "Java version history"[0] page, so it's clear updates stop much sooner than the LTS. [0] https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history
zh3 5y ago
For those of us supporting more than a few legacy apps, use the oldest version (7 in our case) because then there's less chance of things going wrong (depends, of course, whether you bill per support call or a fixed annual fee).
- isbvhodnvemrwvn 5y ago
  I don't understand this way of thinking, do you also run RHEL 4 on your servers?
  - numpad0 5y ago
    That’ll be insane but half-yearly releases of a language spec/language hybrid is insane too, which is what Oracle is doing recently.
  - foepys 5y ago
    Sometimes there is just not enough resources (time, developers, expertise) to update the project. Those projects are often internal and never see the outside of a companies network.
  - zh3 5y ago
    No, too unreliable.
    - deleted 5y ago
      [deleted]
Thev00d00 5y ago
What is this naming? Embarrassing levels of bad "Adoptium Eclipse Temurin OpenJDK "
- shagie 5y ago
  Adoption is the project umbrella under the Eclipse Foundation. Temurin is the project. OpenJDK is the artifact. https://projects.eclipse.org/projects/adoptium https://projects.eclipse.org/projects/adoptium > The mission of the Eclipse Adoptium Top-Level Project is to produce high-quality runtimes and associated technology for use within the Java ecosystem. We achieve this through a set of Projects under the Adoptium PMC and a close working partnership with external projects, most notably OpenJDK for providing the Java SE runtime implementation. Our goal is to meet the needs of both the Eclipse community and broader runtime users by providing a comprehensive set of technologies around runtimes for Java applications that operate alongside existing standards, infrastructures, and cloud platforms. Under Adoption, there is: * Eclipse Adoption Incubator * Eclipse AQAvit * Eclipse Mission Control * Eclipse Temurin Compliance * Eclipse Temurin But yea... the name is awkward.
  - smarx007 5y ago
    https://adoptium.net/ https://adoptium.net/ "Eclipse Temurin is the name of the OpenJDK distribution from Adoptium." Eclipse Temurin 17 or Temurin JDK 17 should be sufficient.
  - tinus_hn 5y ago
    I wonder how good the adoption is for that product. Didn’t they adopt a new name recently?
  - easton 5y ago
    It sounds like something Microsoft would come up with. Well, it's missing a "NT Azure Client Access License". Why didn't they just keep AdoptOpenJDK? That was a good name IMO.
    - shagie 5y ago
chadrs 5y ago
Yeah I agree we should be using 17 except Gradle still does not support it, despite having been out for an entire month... https://docs.gradle.org/current/userguide/compatibility.html https://docs.gradle.org/current/userguide/compatibility.html
- isbvhodnvemrwvn 5y ago
  Isn't that kind of thing you'd expect using Gradle? It's not the first time it happened, they have been late to the party for a lot of the recent releases.
  - geodel 5y ago
    I guess it serves right to folks who endlessly hated Maven and liked this "new", "next generation" , "modern" build system with no XML. Turns out as long as JDK-8 is supported version of Java a lot of tools like this look modern.
    - kaba0 5y ago
      Gradle does fix plenty of shortcomings of Maven, eg. proper parallel builds, proper task graph (you never have to do clean install on gradle, while it is almost always needed with maven), as well as it is much more performant.
- derefr 5y ago
  Technically it's the Groovy runtime that doesn't support 17 (or specifically, JVM bytecode v62+) yet. And then only because it seems to do an explicit whitelisted-version check during some buildscript static-analysis bootstrap phase. If you switch your Gradle buildscript files over to being written in Kotlin, the problem goes away, as Kotlin's runtime doesn't seem to use any similar explicit checks. (Doing so also allows you to go further and test out EA JVM builds, e.g. Project Loom, which Groovy-based buildscripts have never been, and will never be, happy with.)
  - vitus 5y ago
twic 5y ago
I'd like to see more of a rationale for not using Corretto on non-AWS servers. What's wrong with it?
- topspin 5y ago
  I had no idea anyone thought Corretto should be isolated to AWS. I've found nothing wrong with it.
- weissed 5y ago
  I had the same thought, what’s the reason this is not recommended outside AWS?
- distances 5y ago
  I'd also like to know. Even some large Android projects use Corretto.
- verst 5y ago
  And a similar question for the Microsoft build. This isn't Azure or Windows specific at all.
- bombcar 5y ago
  Nothing - but any of the "vendor JDK" they recommend on that vendor's platform only - see RedHat for another example.
- miked85 5y ago
  There isn't any rationale. The author doesn't even attempt to explain the reason behind most recommendations.
- exabrial 5y ago
  Not sure. The JDK works pretty well, but for whatever reason, I had issues with Corretto crypto provider and running it with Metabase. Switched to Adopt and didn't look back
- 8organicbits 5y ago
  The author doesn't justify it but I suspect the thinking is related to how fixes are prioritized. If there is a bug/performance issue that only happens in the context of AWS, then Corretto would be the most likely to rapidly patch the issue as it impacts their customer base. Potentially patches for those sorts of issues would be discovered by AWS through their own use and testing. Likewise for the other vendors and their own platforms.
iamcreasy 5y ago
Why its recommends against using OpenJDK builds by Oracle? Does it come with the same licensing restriction as Oracle JDK?
- aiobe 5y ago
  OpenJDK builds by Oracle are updated only for 6 months, even for LTS versions. Plus these builds are provided for limited platforms only and have no official ready-to-use Docker images.
  - krzyk 5y ago
    Well, I use those, because I uprade every 6 months. And my company forces me to use theirs docker image and I put java on top of it. BTW. Limited platforms, but covers most of the cases (64 bit linux, windows, mac plus aarch64 for linux and mac)
  - miked85 5y ago
    What do Docker images have to do with a JDK decision? Build your own image if you want.
- tyilo 5y ago
  Maybe if you read the page, you'll find out!
  - miked85 5y ago
    The rationale on the page is that the latest LTS version lags the latest release, which is expected and not a good reason to recommend against it.
PaulKeeble 5y ago
It really is quite incredible what a mess has made of the clear stability of Java and what to get since Oracle took over.
- Traubenfuchs 5y ago
  This is not an issue in reality where devs just use whatever chocolately, brew or apt-get pull for them to develop and use whatever is the latest docker image for prod usage.
- ternaryoperator 5y ago
  When Oracle acquired Sun in 2010-11, Sun had not shipped a new release of Java in more than four years.[0] That's hardly a "stability" worth treasuring. Since then, Oracle completely open-sourced the JDK and the associated tools and gave the the compatibility kits to the community to use. The result is that there are now several different distributions of the JDK. This is undeniably a good thing. As to the 6-month release cycle, it allows the community to get new features on a much faster cadence than any of the other major languages. If it's too fast for your preferred way of doing things, stick with the LTS releases, which come out on a three-year cycle and include all the features from the prior releases. There might be reasons not to like Oracle, but their stewardship of Java has been pretty good. [0] https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history
  - sneeeeeed 5y ago
    Since Oracle took over we’ve had a release every few months. That’s terrible. It should be a few weeks, at most.
  - yjftsjthsd-h 5y ago
    > When Oracle acquired Sun in 2010-11, Sun had not shipped a new release of Java in more than four years.[0] That's hardly a "stability" worth treasuring. Sun went several years without releasing a new major version, but that same page lists frequent minor updates. So yes, I would call that exactly a stability to treasure.
spiralpolitik 5y ago
The general guidance is always use the last LTS release unless there is a specific feature in the non LTS releases that you can’t wait for. So any new development should target 17 at this point. Unless you want serious long term pain then you shouldn’t be more than one LTS release behind. So if you are not running on JDK 11 or later you should be strongly thinking about upgrading.
- krzyk 5y ago
  Why should I stick to LTS? All other versions aren't in any way less tested, you should always stick to the newest released JDK version, be it LTS or not, this way you get all the benefits (language features, performance gains) and security ones (security fixes always first land in the newest version, and are backported to the older ones). Upgrades now are pretty straightforward if you are past JKD 9 - with JDK 16-17 being a bit tricky, but less than JDK 9.
  - throw63738 5y ago
    》All other versions aren't in any way less tested Source?
    - evercast 5y ago
      OpenJDK serves as the upstream for many Java distributions (maybe all?) and it has no notion of LTS. LTS is just something to which vendors commit as outlined at https://openjdk.java.net/projects/jdk/17/ https://openjdk.java.net/projects/jdk/17/ : “JDK 17 will be a long-term support (LTS) release from most vendors.”. In other words, OpenJDK does not follow any LTS/non-LTS release cycle. Hence there is nothing special about Java 17 vs 16 when it comes to stability.
    - krzyk 5y ago
      Even preview features are production ready (I used them in production) . Just the api might change or it could be removed, but quality wise it is as good as it can be.
  - 5y ago
smarx007 5y ago
I think this advice only applies to the end users of the JDK and libs, e.g. people who develop webapps. We maintain an OSS library and plan to support JDK 8 for as long as possible (though some of our dependencies made a move to JDK 11 and most likely we'll have to follow suit). With this approach, our libraries can be used by developers under JVM 8, 11, or 17.
- yjftsjthsd-h 5y ago
  Thank you; it is so appreciated when libraries don't abandon old versions.
ahmedfromtunis 5y ago
I wish there were a section like this one in every tools' home/download page. A section called "For production use this" or "if you don't know what you're looking for, use this". And "this" can be a particular version (Ubuntu 20.04.6) or a rule of thumb (for production, always use x.y.1 version or above). Or it can be a table like this one. Django is, as it is in many fields, the gold standard in this regard. It gets confusing sometimes. Yesterday I was trying to update the python version of one of my applications and was wondering; should I do it now, or do I need to wait for 3.10.1? I did it anyway because the app barely gets traffic anyway, but more clarity is always welcome.
dudul 5y ago
Minor typo in the FAQ: "The JRE is a stripped down version of the JRE, and is smaller in terms of Megabytes."
deleted 5y ago
[deleted]
WalterSobchak 5y ago
I wonder why this site doesn't enforce HTTPS, which it clearly supports. https://whichjdk.com/ https://whichjdk.com/
- shartacct 5y ago
  What reason is there to force https on a stateless static page? The content is always the same. You're just ruining caching and wasting CPU cycles.
  - eropple 5y ago
    It protects visitors on compromised networks--and that includes things like ad injectors at coffee shops that might push nasty code to them, not just people dealing with oppressive regimes and so on. It also provides some benefit around "well, that page is HTTPS, so it's more interesting"--if every page is HTTPS, the signaling value of switching to HTTPS is destroyed, and that is a good thing. HTTPS everywhere is a positive, and it is a good thing to do.
    - shartacct 5y ago
      Ad injectors on public wifi is a marginal 'risk' considering this page is targeted to professionals and informed hobbyists anyway, who will predominantly just be browsing from home, work or with a VPN that tunnels traffic through either a server they control or a service provider's server whom they trust anyway.
      - eropple 5y ago
        All risks are marginal when you handwave hard enough. TLS is basically-free in 2021. It's fine and it is good to do.
    - ogurechny 5y ago
      “Specialists” drinking the Kool-Aid look most depressing. Don't you find it strange that each time each proponent believes it's important to mention a stereotypical script kiddie on a public WiFi, something that doesn't bother a lot of people at all because of they way they connect to internet, and hasn't been a common occurrence even in the days of completely broken wireless security protocols? What is/was common is internet providers' interest in making money on personal behavioral data in the traffic they transfer. DPI boxes to passively gather statistics or actively inject ads (and even rewrite existing ads) have been offered and tested since the 2000s across the world. Scale of big ISPs would make them Google's (&Co) competitors on personal behavioral data market, and mobile ISPs would combine it with location data, too. Moreover, they would be able to use Google's own tracking cookies to track individual users instead of inventing the classification systems (either by observing them in clear text, or by injecting scripts). The security and income of web services is the real reason for the global “HTTP is deprecated, switch to HTTPS” campaign, not you and your “privacy”.
TheDesolate0 5y ago
none.
sireat 5y ago
So for those running Scala in production, which version do you use? I am still seeing a lot of projects on 8. New Scala projects are generally on Corretto 11.
- jamesfinlayson 5y ago
  https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html https://docs.scala-lang.org/overviews/jdk-compatibility/over... talks about it a bit but I get the impression Scala is developed using the plain old OpenJDK so that seems like the safest option.
- hocuspocus 5y ago
  I have no problem running web services on the latest JVM, I just migrated a bunch of http4s apps to Temurin Java 17 based docker images. Scala isn't the issue if you can update to the latest patch version; it's more frameworks with outdated Java libraries doing illegal reflective access that are a problem.
094459 5y ago
Thanks for crafting this document, it’s a great start and good to get the discussions started. For me, when I look at which distribution to use I would probably consider other factors that this post doesn’t touch upon completely. What sort of upstream contributions and activity, support across both cloud and on premise and multi architecture support are just a few that come to mind.
pron 5y ago
Here's my recommendation (I work on OpenJDK at Oracle): If you're using the current JDK version (recommended for regularly maintained applications), it doesn't matter which distribution you choose, as they're all pretty much identical. If you're using an old version (LTS, intended for legacy applications, which might benefit from it), pick a vendor you trust for OpenJDK support, as the builds are not the same, and neither is the support. After Oracle, which contributes about 90% of the work on OpenJDK, the companies distributing builds that contribute to the project and have experience with it are (in rough order of experience and/or contribution): Red Hat, SAP, Azul, Bellsoft, and, more recently, Amazon, and Microsoft. There are, however, a couple of standouts: Alibaba's Dragonwell, which, last I looked, did not meet the Java specification, and Eclipse Adoptium, built by IBM, which is the only distribution built by a team that isn't involved with the OpenJDK project, isn't very familiar with it, and isn't a member of the OpenJDK Vulnerability team, and so get security patches only after the other vendors have delivered their builds.
- ed25519FUUU 5y ago
  Interesting about a Adoptium, since that’s the recommended JVM in the article.
  - mayli 5y ago
    I was using adopt jdk since that's much easier to download the jdk (especially jre) for Windows and Linux. The new Adoptium didn't git a jre build, which is sad :(
    - flatiron 5y ago
      Honestly if you are using Linux you should be using the distros Java.
      - krzyk 5y ago
        Why? Distros javas are usually way too old to use.
Decabytes 5y ago
I’ve tried more than once to learn Java I find it very confusing. This website resolves one of the issues. The other issue I have is that most Java tutorials use IntelliJ, or some other IDE, which makes it difficult to figure out what a non IDE workflow actually looks like, some managing dependencies is confusing. I wonder if c# and mono is better in this respect
- Something1234 5y ago
  I think most languages have a really difficult to configure environment if you mess it up or need to keep multiple versions around. Windows is especially bad about it because of the java_home variable. Mono is a mess to configure on Linux, or at least the last time I tried it to learn F#. Java is actually nice in that a lot of distros are packaging a version manager for it. Arch and centos lead the pack in this. Although cent continues to be a mess about how many jdks and Jres are available.
- gadrev 5y ago
  C# in mono has the csharp interactive prompt, and you can also use it to run script files (like .csx). Java often uses IDE but there are tools to run a REPL. Groovy had this before Java got it. You can use it to write Java, since Java code is Groovy. It comes with a GUI console into which you can type and evaluate too, or you can write script files and run them. It's not as fashionable nowadays as it used to be (now it's Kotlin, Scala, etc.) but it works great and can be useful for learning Java too.
- the8472 5y ago
  java itself ships no build and dependency management tools. So you get either the built-in stuff that IDEs offer or use maven, gradle, ant. For toy programs you can also invoke javac directly but as it grows it quickly gets as impractical as compiling large C codebases by hand.
- AmpsterMan 5y ago
  What programming language are you comfortable with? I'd say syntactically Java is fairly simple and at least superficially similar to C/C++. Environment wise, it's definitely very large and oriented toward "powerful but complex" rather than "simple and orthogonal". For build and dependency management systems, Gradle or Maven are your tools. I personally prefer Gradle since it uses a programming language for it's configuration, rather than xml. There is definitely a lack "end-to-end" tutorials that don't rely on some form of tooling support. I would love to see more content on how to make a Java program with nothing but an editor and a command line, but I suspect there isn't much of a need for that. Java's tooling is exceptionally good, it's libraries mature and robust. Part of the reason every tutorial out there uses an IDE is because through quirks of history Java is basically an Enterprise programming environment where "Build the Right Thing" predominates over "Worse is Better". EDIT: There is a REPL included with each JDK after 9 called JShell. It's useful if you just want to get up to speed or if you want to test something quickly.
miked85 5y ago
I find some of these recommendations confusing, there doesn't seem to be reasons to back them. For example: > Use Corretto, only if you run Java applications directly on Amazon Linux 2 in AWS Why?
miked85 5y ago
I've never heard of Adoptium Eclipse Temurin before. It looks like all releases were just within the last few months, but this is the recommendation? Seems a bit strange.
- traspler 5y ago
  It's the successor to AdoptOpenJDK: https://blog.adoptopenjdk.net/2021/03/transition-to-eclipse-an-update/ https://blog.adoptopenjdk.net/2021/03/transition-to-eclipse-...
irq-1 5y ago
Now do .NET :) No, seriously, we need the same thing for .NET
hiram112 5y ago
Thank you for this. I've seen, over the past few years, at least a dozen large threads on HN, Reddit, Slashdot, and elsewhere arguing over the JDK. Usually they're a passionate mix of developers and PMs claiming they're still very confused by the licensing and update / security fix terms since JDK 8, while various Oracle engineers then shout back that the licensing issues are straight forward. Personally, I've developed with Java for over a decade, and I have never really understood when I should use one version or the other. Oracle, Eclipse Foundation, IBM, and the other big players have not done a good job of marketing the various offerings, nor have they done a good job of clarifying for engineers what they should be installing on their local machines, development and test servers, production, etc. This is probably the clearest fact sheet I've seen yet, and the links to different distributions with a concise "Use / Don't Use..." rating is indispensable.
- miked85 5y ago
  The problem is that this page is a very poor resource, with little to nothing backing reasons why one JDK is a better over another.
rococode 5y ago
These recommendations are pretty arbitrary and don't even attempt to scratch the surface of what is actually materially different between the JDKs. Don't use Corretto outside of Amazon... why? Don't use Dragonwell because... China bad? Use Red Hat OpenJDK if you're running on Red Hat servers, Microsoft OpenJDK if you're on Azure, SapMachine if you're on SAP, because... the name matches so that's nice? At least they're consistent on that point. There are (generally pretty niche) reasons to pick specific distros, but those reasons certainly aren't discussed here. I feel like the actual decision process is fairly straightforward in nearly all cases: - Use whatever vendor happens to be most convenient to install. If nearly everyone using your OS is installing Java one way, and you're installing it some other unusual way, you should be crystal clear about why exactly you need to do that. - Generally go with JDK 11, if you may have to deal with older software then maybe go with 8, if you want the shiny new stuff and don't mind some extra hassle then go with JDK 17 (it's not well-supported by everything yet). That's pretty much it. There are exceedingly few cases where it actually matters whether you installed Corretto or Oracle OpenJDK, and in those cases you'll likely end up either testing all the JDKs anyway to make your decision or writing your own patches for whatever you need.
- morpheuskafka 5y ago
  > Use Red Hat OpenJDK if you're running on Red Hat servers, Microsoft OpenJDK if you're on Azure, SapMachine if you're on SAP, because... the name matches so that's nice? Presumably this has to do with support and possible testing. People buy RedHat EL for the longterm support, if they use a different vendor for the JDK they have to set up a whole new contract for that with a different company. By contrast, people using a free Linux distro may not have any benefit to using RedHat's JDK.
  - zaphirplane 5y ago
    These statement about support i just don’t get at an objective level. Redhat will not assign a strong developer to investigate your bespoke application running on tomcat or whatever to identify the bug. Possible pragmatic reasons You will get a l2 sysAdmin or an intermediate developer. If for some reason the root cause is nailed to a reproducible bug then it will go into the bug tracker
ypcx 5y ago
Use Openj9 to lower your RAM requirements. Use HotSpot for compatibility with tools like heap/thread dumpers and I guess profilers/debuggers.
underscore_ku 5y ago
java --version openjdk 11.0.11 2021-04-20 OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2) OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2, mixed mode, sharing)
thayne 5y ago
How do the versions in linux package repositories fit into this? It mentions Red Hat, but what about the packages for Debian/Ubuntu, OpenSUSE, etc.
ryanmarsh 5y ago
What a zoo. So glad I’m not trying to deploy Java workloads anymore. It used to be the best JVM was the Sun JVM and everyone used it.
agilob 5y ago
Highlights column only includes syntax sugar or syntactical functionality, but nothing about ZGC, shenandoah, compact metaspace? Very unfair.
armchairhacker 5y ago
I was literally just looking at JDK comparisons out of interest (I already have my app running under a JDK). But I'm still not convinced which is the "best" one. What are some difference between OpenJDK, Adoptium, Azul, BellSoft, etc. besides company dependencies and lifecycle? Which JDK is the fastest, or do certain JDKs perform faster under certain scenarios? Do any of these JDKs have any special features, or can they not do certain advanced reflection (e.g. for efficiency?) I use IntelliJ so switching JDK is very easy, and most apps work on any JDK. Plus I doubt anything I release would be relevant in the long term (at least without the ability to upgrade JDK). So I really don't have to depend on any JDK, and seems like I don't have to worry about my JDK getting obsolete. Is there still a reason why I would prefer to use one JDK over another?
- jamesfinlayson 5y ago
  I think most JDKs these days are running mostly the same code (Oracle's Java) though a lot of them have little extra improvements or fixes (and some have longer support periods too). I try and stick with OpenJDK as that's the default Java implementation and it's probably a sensible default unless you have a requirement that one of the other ones specifically meets (like extended Java 8 security patches).
jaimex2 5y ago
Something went terribly wrong after Java 8. A lot of apps just got stuck there.
deleted 5y ago
[deleted]
vbezhenar 5y ago
Use Oracle JDK 17.
shp0ngle 5y ago
"Adoptium Eclipse Temurin" ....ok
kburman 5y ago
Who would anyone be using Chinese SDK? Recent Mi phone revelation are not enough?
- kaba0 5y ago
  Is “Chinese” a single entity?
- 5e92cb50239222b 5y ago
  Not that many years ago you'd be writing the exact same thing about USSR. It's pretty funny to watch as an outsider who has zero stakes in either side.
giords 5y ago
IMHO this mess will hurt Java on the medium-long run. All of this is unnecessarily complicated and confusing, as a developer it really feels like they don't want me to use Java. I have the feeling that, similarly to what happened with the Roman empire, greed, laziness and burocracy are going to drag everything down.
- vbezhenar 5y ago
  How is it a mess? You have official Oracle JDK build. You have official Oracle OpenJDK build. You have plenty of alternative builds. It's like kernel.org Linux, Debian Linux, Fedora Linux and so on. Does it hurt Linux? I don't think so. All builds should be perfectly compatible between each other. Simplest way is just use Oracle JDK 17. It's LTS, free and official.
  - signal11 5y ago
    I largely agree, but would only say -- consider if your use-case needs LTS[1]. Not every use-case does. [1] https://news.ycombinator.com/item?id=26478175 https://news.ycombinator.com/item?id=26478175
  - giords 5y ago
    It's a mess because for the average joe such as myself it's very confusing and foggy. There's an Oracle jdk whose usage terms need to be deciphered using a lawyer to understand precisely when and how you can use it. So much that the average advice is to not use it. Like if they told you "hey, node.js is cool but don't use the one from those who maintain and develop the code". This would be a huge red flag for any other language than Java, which can leverage 30 years of sunk costs for companies that now will not switch lightly to something else. The alternative builds are good, yet not official and they might introduce thin incompatibilities or different behaviors. They should not but this whole article suggests that they actually do. The simple existence of articles like this one testifies that this is a mess for a lot of people.
    - absove 5y ago
      If you're on linux, use the openjdk build from your distro's official repository. If you're on windows, download the latest openjdk build from oracle (currently https://jdk.java.net/17/ https://jdk.java.net/17/), extract somewhere, put /bin folder on path. Optionally set JAVA_HOME env variable to the main folder path. No clue about OSX but it's probably similar to windows. Ignore oracle jdk, ignore any concept of LTS/not-LTS, that's only for companies with big pockets and specific needs. People really like to make it sound more complicated than it actually is.
T3RMINATED 5y ago
Easy answer: none - get rid of Java.
lbayes 5y ago
(deleted stupid comment) apologies!
- nikanj 5y ago
  Please don't post this edgy trolling here.
  - lbayes 5y ago
    You're right. Thanks for calling it out.

329 points by aiobe 5y ago

What a great site! I have often wondered about these things but I'm not a Java guy so I never investigated for myself. I've never heard of Adoptium before but it sounds like the right choice.

bombcar 5y ago

No mention of GraalVM - https://www.graalvm.org https://www.graalvm.org - perhaps because it's Oracle?

kaba0 5y ago
Graal is (also) a goddamn Oracle project, smh… The reason it doesn’t mention it is because it is a useless website.

nlitened 5y ago

Is there a way to apt-get the new JDK 17 as a package on Ubuntu, instead of piping a shell script from curl or unzipping a tar? Does anybody use package managers on Linux anymore?

needusername 5y ago
Getting Java through apt-get gives you more or less the worst quality builds https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009330.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/0... You get mystery bits that haven't been put through the TCK.
- nlitened 5y ago
  I think a custom package repository could be a proper solution then. This way one would get version upgrades for free. Much better than installing (curl-piping) yet another package management tool `sdkman` with a new syntax. Though, I might be missing some important details, and I would love to understand it better. Edit: a sibling comment suggested that now there's a package repository for that, and indeed there is.
severino 5y ago
Last time I checked, at least in Ubuntu 20.04, there was already a package for OpenJDK 17, so I think that's the straightforward and recommended way to get Java 17 in Ubuntu.
- nlitened 5y ago
  Wow, you're actually right — I wasn't able to find it before (maybe Java 17 was too new back then). If anybody's interested: sudo add-apt-repository ppa:linuxuprising/java sudo apt-get update sudo apt-get install oracle-java17-installer oracle-java17-set-default
  - severino 5y ago
    Yes, I checked some weeks ago and v.16 was the last one, so I guess it was too soon. However, you don't need a special repo for getting OpenJDK 17. Yours is for getting Oracle JDK 17, right?
Freak_NL 5y ago
I don't like the 'curl -s "https://XXX https://XXX" | bash' approach much either, but I've given up trying to work around it. With SDKMan switching between JDKs is painless, despite the install method of SDKMan itself being one of those. But it's not just Java. To build our frontend webapp I need NodeJS, and there too some specific version depending on the version of the webapp or just because we've updated. I'd love to be able to just apt install all of this, but the downsides are just too many.
- KronisLV 5y ago
  Personally, i just use containers to manage business applications - which often need a very particular runtime that's tested, verified and signed off on for maximum stability and predictable deployments. On the other hand, i only use standard packages through apt/yum/apk/whatever for server software, a distinction that's lost too often in my opinion. Everything that the server needs to operate should have automatic (at least security) updates enabled and ideally the configuration should be fully automated through Ansible with something like GitOps and read only access through SSH (with fallback account with write access for special cases) for maximum auditability and being sure that this is less likely to happen: https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/ https://dougseven.com/2014/04/17/knightmare-a-devops-caution... Furthermore, the servers themselves can be viewed as pretty much disposable at that point. A VM gets corrupted? Wipe it, create a new one, run Ansible against it to set up the environment, then just give the node a label in your container orchestration platform of choice and watch as your business software is automatically provisioned on the node, bringing the total capacity of your cluster up once again. For personal devices with no important credentials, or development boxes which are similarly unimportant, piping random stuff and trying to work around the problems with multiple SDKs is more permissible, however. Seeing as PHP, Ruby, Go, Java, .NET, Python and other technologies aren't always pleasant to work with if you have different projects that need different environments, as humorously pointed out here: https://xkcd.com/1987/ https://xkcd.com/1987/ Containers aren't always comfortable to use for local development (especially with OSes like Windows locally, without WSL2, due to problems with bind mounts but perhaps are for components like DBs, Redis, MongoDB etc.), but in certain dev boxes they are also viable, thus making development even easier.

karmakaze 5y ago

This page should definitely have a "end of free public updates" column as is shown on the "Java version history"[0] page, so it's clear updates stop much sooner than the LTS. [0] https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history

zh3 5y ago

For those of us supporting more than a few legacy apps, use the oldest version (7 in our case) because then there's less chance of things going wrong (depends, of course, whether you bill per support call or a fixed annual fee).

isbvhodnvemrwvn 5y ago
I don't understand this way of thinking, do you also run RHEL 4 on your servers?
- numpad0 5y ago
  That’ll be insane but half-yearly releases of a language spec/language hybrid is insane too, which is what Oracle is doing recently.
- foepys 5y ago
  Sometimes there is just not enough resources (time, developers, expertise) to update the project. Those projects are often internal and never see the outside of a companies network.
- zh3 5y ago
  No, too unreliable.
  - deleted 5y ago
    [deleted]

Thev00d00 5y ago

What is this naming? Embarrassing levels of bad "Adoptium Eclipse Temurin OpenJDK "

shagie 5y ago
Adoption is the project umbrella under the Eclipse Foundation. Temurin is the project. OpenJDK is the artifact. https://projects.eclipse.org/projects/adoptium https://projects.eclipse.org/projects/adoptium > The mission of the Eclipse Adoptium Top-Level Project is to produce high-quality runtimes and associated technology for use within the Java ecosystem. We achieve this through a set of Projects under the Adoptium PMC and a close working partnership with external projects, most notably OpenJDK for providing the Java SE runtime implementation. Our goal is to meet the needs of both the Eclipse community and broader runtime users by providing a comprehensive set of technologies around runtimes for Java applications that operate alongside existing standards, infrastructures, and cloud platforms. Under Adoption, there is: * Eclipse Adoption Incubator * Eclipse AQAvit * Eclipse Mission Control * Eclipse Temurin Compliance * Eclipse Temurin But yea... the name is awkward.
- smarx007 5y ago
  https://adoptium.net/ https://adoptium.net/ "Eclipse Temurin is the name of the OpenJDK distribution from Adoptium." Eclipse Temurin 17 or Temurin JDK 17 should be sufficient.
- tinus_hn 5y ago
  I wonder how good the adoption is for that product. Didn’t they adopt a new name recently?
- easton 5y ago
  It sounds like something Microsoft would come up with. Well, it's missing a "NT Azure Client Access License". Why didn't they just keep AdoptOpenJDK? That was a good name IMO.
  - shagie 5y ago

chadrs 5y ago

Yeah I agree we should be using 17 except Gradle still does not support it, despite having been out for an entire month... https://docs.gradle.org/current/userguide/compatibility.html https://docs.gradle.org/current/userguide/compatibility.html

isbvhodnvemrwvn 5y ago
Isn't that kind of thing you'd expect using Gradle? It's not the first time it happened, they have been late to the party for a lot of the recent releases.
- geodel 5y ago
  I guess it serves right to folks who endlessly hated Maven and liked this "new", "next generation" , "modern" build system with no XML. Turns out as long as JDK-8 is supported version of Java a lot of tools like this look modern.
  - kaba0 5y ago
    Gradle does fix plenty of shortcomings of Maven, eg. proper parallel builds, proper task graph (you never have to do clean install on gradle, while it is almost always needed with maven), as well as it is much more performant.
derefr 5y ago
Technically it's the Groovy runtime that doesn't support 17 (or specifically, JVM bytecode v62+) yet. And then only because it seems to do an explicit whitelisted-version check during some buildscript static-analysis bootstrap phase. If you switch your Gradle buildscript files over to being written in Kotlin, the problem goes away, as Kotlin's runtime doesn't seem to use any similar explicit checks. (Doing so also allows you to go further and test out EA JVM builds, e.g. Project Loom, which Groovy-based buildscripts have never been, and will never be, happy with.)
- vitus 5y ago

twic 5y ago

I'd like to see more of a rationale for not using Corretto on non-AWS servers. What's wrong with it?

topspin 5y ago
I had no idea anyone thought Corretto should be isolated to AWS. I've found nothing wrong with it.
weissed 5y ago
I had the same thought, what’s the reason this is not recommended outside AWS?
distances 5y ago
I'd also like to know. Even some large Android projects use Corretto.
verst 5y ago
And a similar question for the Microsoft build. This isn't Azure or Windows specific at all.
bombcar 5y ago
Nothing - but any of the "vendor JDK" they recommend on that vendor's platform only - see RedHat for another example.
miked85 5y ago
There isn't any rationale. The author doesn't even attempt to explain the reason behind most recommendations.
exabrial 5y ago
Not sure. The JDK works pretty well, but for whatever reason, I had issues with Corretto crypto provider and running it with Metabase. Switched to Adopt and didn't look back
8organicbits 5y ago
The author doesn't justify it but I suspect the thinking is related to how fixes are prioritized. If there is a bug/performance issue that only happens in the context of AWS, then Corretto would be the most likely to rapidly patch the issue as it impacts their customer base. Potentially patches for those sorts of issues would be discovered by AWS through their own use and testing. Likewise for the other vendors and their own platforms.

iamcreasy 5y ago

Why its recommends against using OpenJDK builds by Oracle? Does it come with the same licensing restriction as Oracle JDK?

aiobe 5y ago
OpenJDK builds by Oracle are updated only for 6 months, even for LTS versions. Plus these builds are provided for limited platforms only and have no official ready-to-use Docker images.
- krzyk 5y ago
  Well, I use those, because I uprade every 6 months. And my company forces me to use theirs docker image and I put java on top of it. BTW. Limited platforms, but covers most of the cases (64 bit linux, windows, mac plus aarch64 for linux and mac)
- miked85 5y ago
  What do Docker images have to do with a JDK decision? Build your own image if you want.
tyilo 5y ago
Maybe if you read the page, you'll find out!
- miked85 5y ago
  The rationale on the page is that the latest LTS version lags the latest release, which is expected and not a good reason to recommend against it.

PaulKeeble 5y ago

It really is quite incredible what a mess has made of the clear stability of Java and what to get since Oracle took over.

Traubenfuchs 5y ago
This is not an issue in reality where devs just use whatever chocolately, brew or apt-get pull for them to develop and use whatever is the latest docker image for prod usage.
ternaryoperator 5y ago
When Oracle acquired Sun in 2010-11, Sun had not shipped a new release of Java in more than four years.[0] That's hardly a "stability" worth treasuring. Since then, Oracle completely open-sourced the JDK and the associated tools and gave the the compatibility kits to the community to use. The result is that there are now several different distributions of the JDK. This is undeniably a good thing. As to the 6-month release cycle, it allows the community to get new features on a much faster cadence than any of the other major languages. If it's too fast for your preferred way of doing things, stick with the LTS releases, which come out on a three-year cycle and include all the features from the prior releases. There might be reasons not to like Oracle, but their stewardship of Java has been pretty good. [0] https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history
- sneeeeeed 5y ago
  Since Oracle took over we’ve had a release every few months. That’s terrible. It should be a few weeks, at most.
- yjftsjthsd-h 5y ago
  > When Oracle acquired Sun in 2010-11, Sun had not shipped a new release of Java in more than four years.[0] That's hardly a "stability" worth treasuring. Sun went several years without releasing a new major version, but that same page lists frequent minor updates. So yes, I would call that exactly a stability to treasure.

spiralpolitik 5y ago

The general guidance is always use the last LTS release unless there is a specific feature in the non LTS releases that you can’t wait for. So any new development should target 17 at this point. Unless you want serious long term pain then you shouldn’t be more than one LTS release behind. So if you are not running on JDK 11 or later you should be strongly thinking about upgrading.

krzyk 5y ago
Why should I stick to LTS? All other versions aren't in any way less tested, you should always stick to the newest released JDK version, be it LTS or not, this way you get all the benefits (language features, performance gains) and security ones (security fixes always first land in the newest version, and are backported to the older ones). Upgrades now are pretty straightforward if you are past JKD 9 - with JDK 16-17 being a bit tricky, but less than JDK 9.
- throw63738 5y ago
  》All other versions aren't in any way less tested Source?
  - evercast 5y ago
    OpenJDK serves as the upstream for many Java distributions (maybe all?) and it has no notion of LTS. LTS is just something to which vendors commit as outlined at https://openjdk.java.net/projects/jdk/17/ https://openjdk.java.net/projects/jdk/17/ : “JDK 17 will be a long-term support (LTS) release from most vendors.”. In other words, OpenJDK does not follow any LTS/non-LTS release cycle. Hence there is nothing special about Java 17 vs 16 when it comes to stability.
  - krzyk 5y ago
    Even preview features are production ready (I used them in production) . Just the api might change or it could be removed, but quality wise it is as good as it can be.
- 5y ago

smarx007 5y ago

I think this advice only applies to the end users of the JDK and libs, e.g. people who develop webapps. We maintain an OSS library and plan to support JDK 8 for as long as possible (though some of our dependencies made a move to JDK 11 and most likely we'll have to follow suit). With this approach, our libraries can be used by developers under JVM 8, 11, or 17.

yjftsjthsd-h 5y ago
Thank you; it is so appreciated when libraries don't abandon old versions.

ahmedfromtunis 5y ago

I wish there were a section like this one in every tools' home/download page. A section called "For production use this" or "if you don't know what you're looking for, use this". And "this" can be a particular version (Ubuntu 20.04.6) or a rule of thumb (for production, always use x.y.1 version or above). Or it can be a table like this one. Django is, as it is in many fields, the gold standard in this regard. It gets confusing sometimes. Yesterday I was trying to update the python version of one of my applications and was wondering; should I do it now, or do I need to wait for 3.10.1? I did it anyway because the app barely gets traffic anyway, but more clarity is always welcome.

dudul 5y ago

Minor typo in the FAQ: "The JRE is a stripped down version of the JRE, and is smaller in terms of Megabytes."

deleted 5y ago

[deleted]

WalterSobchak 5y ago

I wonder why this site doesn't enforce HTTPS, which it clearly supports. https://whichjdk.com/ https://whichjdk.com/

shartacct 5y ago
What reason is there to force https on a stateless static page? The content is always the same. You're just ruining caching and wasting CPU cycles.
- eropple 5y ago
  It protects visitors on compromised networks--and that includes things like ad injectors at coffee shops that might push nasty code to them, not just people dealing with oppressive regimes and so on. It also provides some benefit around "well, that page is HTTPS, so it's more interesting"--if every page is HTTPS, the signaling value of switching to HTTPS is destroyed, and that is a good thing. HTTPS everywhere is a positive, and it is a good thing to do.
  - shartacct 5y ago
    Ad injectors on public wifi is a marginal 'risk' considering this page is targeted to professionals and informed hobbyists anyway, who will predominantly just be browsing from home, work or with a VPN that tunnels traffic through either a server they control or a service provider's server whom they trust anyway.
    - eropple 5y ago
      All risks are marginal when you handwave hard enough. TLS is basically-free in 2021. It's fine and it is good to do.
  - ogurechny 5y ago
    “Specialists” drinking the Kool-Aid look most depressing. Don't you find it strange that each time each proponent believes it's important to mention a stereotypical script kiddie on a public WiFi, something that doesn't bother a lot of people at all because of they way they connect to internet, and hasn't been a common occurrence even in the days of completely broken wireless security protocols? What is/was common is internet providers' interest in making money on personal behavioral data in the traffic they transfer. DPI boxes to passively gather statistics or actively inject ads (and even rewrite existing ads) have been offered and tested since the 2000s across the world. Scale of big ISPs would make them Google's (&Co) competitors on personal behavioral data market, and mobile ISPs would combine it with location data, too. Moreover, they would be able to use Google's own tracking cookies to track individual users instead of inventing the classification systems (either by observing them in clear text, or by injecting scripts). The security and income of web services is the real reason for the global “HTTP is deprecated, switch to HTTPS” campaign, not you and your “privacy”.

TheDesolate0 5y ago

none.

sireat 5y ago

So for those running Scala in production, which version do you use? I am still seeing a lot of projects on 8. New Scala projects are generally on Corretto 11.

jamesfinlayson 5y ago
https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html https://docs.scala-lang.org/overviews/jdk-compatibility/over... talks about it a bit but I get the impression Scala is developed using the plain old OpenJDK so that seems like the safest option.
hocuspocus 5y ago
I have no problem running web services on the latest JVM, I just migrated a bunch of http4s apps to Temurin Java 17 based docker images. Scala isn't the issue if you can update to the latest patch version; it's more frameworks with outdated Java libraries doing illegal reflective access that are a problem.

094459 5y ago

Thanks for crafting this document, it’s a great start and good to get the discussions started. For me, when I look at which distribution to use I would probably consider other factors that this post doesn’t touch upon completely. What sort of upstream contributions and activity, support across both cloud and on premise and multi architecture support are just a few that come to mind.

pron 5y ago

Here's my recommendation (I work on OpenJDK at Oracle): If you're using the current JDK version (recommended for regularly maintained applications), it doesn't matter which distribution you choose, as they're all pretty much identical. If you're using an old version (LTS, intended for legacy applications, which might benefit from it), pick a vendor you trust for OpenJDK support, as the builds are not the same, and neither is the support. After Oracle, which contributes about 90% of the work on OpenJDK, the companies distributing builds that contribute to the project and have experience with it are (in rough order of experience and/or contribution): Red Hat, SAP, Azul, Bellsoft, and, more recently, Amazon, and Microsoft. There are, however, a couple of standouts: Alibaba's Dragonwell, which, last I looked, did not meet the Java specification, and Eclipse Adoptium, built by IBM, which is the only distribution built by a team that isn't involved with the OpenJDK project, isn't very familiar with it, and isn't a member of the OpenJDK Vulnerability team, and so get security patches only after the other vendors have delivered their builds.

ed25519FUUU 5y ago
Interesting about a Adoptium, since that’s the recommended JVM in the article.
- mayli 5y ago
  I was using adopt jdk since that's much easier to download the jdk (especially jre) for Windows and Linux. The new Adoptium didn't git a jre build, which is sad :(
  - flatiron 5y ago
    Honestly if you are using Linux you should be using the distros Java.
    - krzyk 5y ago
      Why? Distros javas are usually way too old to use.

Decabytes 5y ago

I’ve tried more than once to learn Java I find it very confusing. This website resolves one of the issues. The other issue I have is that most Java tutorials use IntelliJ, or some other IDE, which makes it difficult to figure out what a non IDE workflow actually looks like, some managing dependencies is confusing. I wonder if c# and mono is better in this respect

Something1234 5y ago
I think most languages have a really difficult to configure environment if you mess it up or need to keep multiple versions around. Windows is especially bad about it because of the java_home variable. Mono is a mess to configure on Linux, or at least the last time I tried it to learn F#. Java is actually nice in that a lot of distros are packaging a version manager for it. Arch and centos lead the pack in this. Although cent continues to be a mess about how many jdks and Jres are available.
gadrev 5y ago
C# in mono has the csharp interactive prompt, and you can also use it to run script files (like .csx). Java often uses IDE but there are tools to run a REPL. Groovy had this before Java got it. You can use it to write Java, since Java code is Groovy. It comes with a GUI console into which you can type and evaluate too, or you can write script files and run them. It's not as fashionable nowadays as it used to be (now it's Kotlin, Scala, etc.) but it works great and can be useful for learning Java too.
the8472 5y ago
java itself ships no build and dependency management tools. So you get either the built-in stuff that IDEs offer or use maven, gradle, ant. For toy programs you can also invoke javac directly but as it grows it quickly gets as impractical as compiling large C codebases by hand.
AmpsterMan 5y ago
What programming language are you comfortable with? I'd say syntactically Java is fairly simple and at least superficially similar to C/C++. Environment wise, it's definitely very large and oriented toward "powerful but complex" rather than "simple and orthogonal". For build and dependency management systems, Gradle or Maven are your tools. I personally prefer Gradle since it uses a programming language for it's configuration, rather than xml. There is definitely a lack "end-to-end" tutorials that don't rely on some form of tooling support. I would love to see more content on how to make a Java program with nothing but an editor and a command line, but I suspect there isn't much of a need for that. Java's tooling is exceptionally good, it's libraries mature and robust. Part of the reason every tutorial out there uses an IDE is because through quirks of history Java is basically an Enterprise programming environment where "Build the Right Thing" predominates over "Worse is Better". EDIT: There is a REPL included with each JDK after 9 called JShell. It's useful if you just want to get up to speed or if you want to test something quickly.

miked85 5y ago

I find some of these recommendations confusing, there doesn't seem to be reasons to back them. For example: > Use Corretto, only if you run Java applications directly on Amazon Linux 2 in AWS Why?

miked85 5y ago

I've never heard of Adoptium Eclipse Temurin before. It looks like all releases were just within the last few months, but this is the recommendation? Seems a bit strange.

traspler 5y ago
It's the successor to AdoptOpenJDK: https://blog.adoptopenjdk.net/2021/03/transition-to-eclipse-an-update/ https://blog.adoptopenjdk.net/2021/03/transition-to-eclipse-...

irq-1 5y ago

Now do .NET :) No, seriously, we need the same thing for .NET

hiram112 5y ago

Thank you for this. I've seen, over the past few years, at least a dozen large threads on HN, Reddit, Slashdot, and elsewhere arguing over the JDK. Usually they're a passionate mix of developers and PMs claiming they're still very confused by the licensing and update / security fix terms since JDK 8, while various Oracle engineers then shout back that the licensing issues are straight forward. Personally, I've developed with Java for over a decade, and I have never really understood when I should use one version or the other. Oracle, Eclipse Foundation, IBM, and the other big players have not done a good job of marketing the various offerings, nor have they done a good job of clarifying for engineers what they should be installing on their local machines, development and test servers, production, etc. This is probably the clearest fact sheet I've seen yet, and the links to different distributions with a concise "Use / Don't Use..." rating is indispensable.

miked85 5y ago
The problem is that this page is a very poor resource, with little to nothing backing reasons why one JDK is a better over another.

rococode 5y ago

These recommendations are pretty arbitrary and don't even attempt to scratch the surface of what is actually materially different between the JDKs. Don't use Corretto outside of Amazon... why? Don't use Dragonwell because... China bad? Use Red Hat OpenJDK if you're running on Red Hat servers, Microsoft OpenJDK if you're on Azure, SapMachine if you're on SAP, because... the name matches so that's nice? At least they're consistent on that point. There are (generally pretty niche) reasons to pick specific distros, but those reasons certainly aren't discussed here. I feel like the actual decision process is fairly straightforward in nearly all cases: - Use whatever vendor happens to be most convenient to install. If nearly everyone using your OS is installing Java one way, and you're installing it some other unusual way, you should be crystal clear about why exactly you need to do that. - Generally go with JDK 11, if you may have to deal with older software then maybe go with 8, if you want the shiny new stuff and don't mind some extra hassle then go with JDK 17 (it's not well-supported by everything yet). That's pretty much it. There are exceedingly few cases where it actually matters whether you installed Corretto or Oracle OpenJDK, and in those cases you'll likely end up either testing all the JDKs anyway to make your decision or writing your own patches for whatever you need.

morpheuskafka 5y ago
> Use Red Hat OpenJDK if you're running on Red Hat servers, Microsoft OpenJDK if you're on Azure, SapMachine if you're on SAP, because... the name matches so that's nice? Presumably this has to do with support and possible testing. People buy RedHat EL for the longterm support, if they use a different vendor for the JDK they have to set up a whole new contract for that with a different company. By contrast, people using a free Linux distro may not have any benefit to using RedHat's JDK.
- zaphirplane 5y ago
  These statement about support i just don’t get at an objective level. Redhat will not assign a strong developer to investigate your bespoke application running on tomcat or whatever to identify the bug. Possible pragmatic reasons You will get a l2 sysAdmin or an intermediate developer. If for some reason the root cause is nailed to a reproducible bug then it will go into the bug tracker

ypcx 5y ago

Use Openj9 to lower your RAM requirements. Use HotSpot for compatibility with tools like heap/thread dumpers and I guess profilers/debuggers.

underscore_ku 5y ago

java --version openjdk 11.0.11 2021-04-20 OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2) OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2, mixed mode, sharing)

thayne 5y ago

How do the versions in linux package repositories fit into this? It mentions Red Hat, but what about the packages for Debian/Ubuntu, OpenSUSE, etc.

ryanmarsh 5y ago

What a zoo. So glad I’m not trying to deploy Java workloads anymore. It used to be the best JVM was the Sun JVM and everyone used it.

agilob 5y ago

Highlights column only includes syntax sugar or syntactical functionality, but nothing about ZGC, shenandoah, compact metaspace? Very unfair.

armchairhacker 5y ago

I was literally just looking at JDK comparisons out of interest (I already have my app running under a JDK). But I'm still not convinced which is the "best" one. What are some difference between OpenJDK, Adoptium, Azul, BellSoft, etc. besides company dependencies and lifecycle? Which JDK is the fastest, or do certain JDKs perform faster under certain scenarios? Do any of these JDKs have any special features, or can they not do certain advanced reflection (e.g. for efficiency?) I use IntelliJ so switching JDK is very easy, and most apps work on any JDK. Plus I doubt anything I release would be relevant in the long term (at least without the ability to upgrade JDK). So I really don't have to depend on any JDK, and seems like I don't have to worry about my JDK getting obsolete. Is there still a reason why I would prefer to use one JDK over another?

jamesfinlayson 5y ago
I think most JDKs these days are running mostly the same code (Oracle's Java) though a lot of them have little extra improvements or fixes (and some have longer support periods too). I try and stick with OpenJDK as that's the default Java implementation and it's probably a sensible default unless you have a requirement that one of the other ones specifically meets (like extended Java 8 security patches).

jaimex2 5y ago

Something went terribly wrong after Java 8. A lot of apps just got stuck there.

deleted 5y ago

[deleted]

vbezhenar 5y ago

Use Oracle JDK 17.

shp0ngle 5y ago

"Adoptium Eclipse Temurin" ....ok

kburman 5y ago

Who would anyone be using Chinese SDK? Recent Mi phone revelation are not enough?

kaba0 5y ago
Is “Chinese” a single entity?
5e92cb50239222b 5y ago
Not that many years ago you'd be writing the exact same thing about USSR. It's pretty funny to watch as an outsider who has zero stakes in either side.

giords 5y ago

IMHO this mess will hurt Java on the medium-long run. All of this is unnecessarily complicated and confusing, as a developer it really feels like they don't want me to use Java. I have the feeling that, similarly to what happened with the Roman empire, greed, laziness and burocracy are going to drag everything down.

vbezhenar 5y ago
How is it a mess? You have official Oracle JDK build. You have official Oracle OpenJDK build. You have plenty of alternative builds. It's like kernel.org Linux, Debian Linux, Fedora Linux and so on. Does it hurt Linux? I don't think so. All builds should be perfectly compatible between each other. Simplest way is just use Oracle JDK 17. It's LTS, free and official.
- signal11 5y ago
  I largely agree, but would only say -- consider if your use-case needs LTS[1]. Not every use-case does. [1] https://news.ycombinator.com/item?id=26478175 https://news.ycombinator.com/item?id=26478175
- giords 5y ago
  It's a mess because for the average joe such as myself it's very confusing and foggy. There's an Oracle jdk whose usage terms need to be deciphered using a lawyer to understand precisely when and how you can use it. So much that the average advice is to not use it. Like if they told you "hey, node.js is cool but don't use the one from those who maintain and develop the code". This would be a huge red flag for any other language than Java, which can leverage 30 years of sunk costs for companies that now will not switch lightly to something else. The alternative builds are good, yet not official and they might introduce thin incompatibilities or different behaviors. They should not but this whole article suggests that they actually do. The simple existence of articles like this one testifies that this is a mess for a lot of people.
  - absove 5y ago
    If you're on linux, use the openjdk build from your distro's official repository. If you're on windows, download the latest openjdk build from oracle (currently https://jdk.java.net/17/ https://jdk.java.net/17/), extract somewhere, put /bin folder on path. Optionally set JAVA_HOME env variable to the main folder path. No clue about OSX but it's probably similar to windows. Ignore oracle jdk, ignore any concept of LTS/not-LTS, that's only for companies with big pockets and specific needs. People really like to make it sound more complicated than it actually is.

T3RMINATED 5y ago

Easy answer: none - get rid of Java.

lbayes 5y ago

(deleted stupid comment) apologies!

nikanj 5y ago
Please don't post this edgy trolling here.
- lbayes 5y ago
  You're right. Thanks for calling it out.