3 ms·

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 Co

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
  - unnah 5y ago
    A few years back I contacted SUSE support due to a confusing package change in a SUSE upgrade. The first-level support person did not know the answer, so they reached out to the relevant developer within SUSE, and got the explanation within a couple of days. Do you have any reason to expect Red Hat support to perform worse?
    - zaphirplane 5y ago
      How do I do x, is very very different from in my custom environment with custom code sometimes foo doesn’t happen when bar is triggered Personal experience, some very nice bright people there but also work for a company
- MichaelMoser123 5y ago
  i think it has to do with that image is quicker to load. if you are using the coretto image(aws) on azure, then you are not guaranteed that the local docker repository has it cached, so it will take very long to load. Also support will be more difficult, if you use the non native image.
deleted 5y ago
[deleted]
shp0ngle 5y ago
Yeah, this recommendation is very random
jeff_carr 5y ago
> Use whatever vendor happens to be most convenient to install Yes -- do what everyone else does. > Generally go with JDK 11 Seconded. User rococode is dead on correct here.
deepsun 5y ago
> the name matches so that's nice? To me it sounds reasonable that Microsoft tests/optimizes their JDK better for Azure, and Amazon -- for AWS.
- dncornholio 5y ago
  Assumptions are the mother of all fuck-ups..
pron 5y ago
> Generally go with JDK 11, if you may have to deal with older software then maybe go with 8 That's a good recommendation for library authors, but if you're deploying an application that's regularly maintained, I would recommend using the most recent version -- that's the cheapest, safest way -- and if it isn't, consider an old version (like 11) with one of the LTS offerings, choosing a vendor you trust to support OpenJDK (https://news.ycombinator.com/item?id=28821316 https://news.ycombinator.com/item?id=28821316). Of course, new applications should now target 17. It's both the current version and it has LTS.

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
- unnah 5y ago
  A few years back I contacted SUSE support due to a confusing package change in a SUSE upgrade. The first-level support person did not know the answer, so they reached out to the relevant developer within SUSE, and got the explanation within a couple of days. Do you have any reason to expect Red Hat support to perform worse?
  - zaphirplane 5y ago
    How do I do x, is very very different from in my custom environment with custom code sometimes foo doesn’t happen when bar is triggered Personal experience, some very nice bright people there but also work for a company
MichaelMoser123 5y ago
i think it has to do with that image is quicker to load. if you are using the coretto image(aws) on azure, then you are not guaranteed that the local docker repository has it cached, so it will take very long to load. Also support will be more difficult, if you use the non native image.

deleted 5y ago

[deleted]

shp0ngle 5y ago

Yeah, this recommendation is very random

jeff_carr 5y ago

> Use whatever vendor happens to be most convenient to install Yes -- do what everyone else does. > Generally go with JDK 11 Seconded. User rococode is dead on correct here.

deepsun 5y ago

> the name matches so that's nice? To me it sounds reasonable that Microsoft tests/optimizes their JDK better for Azure, and Amazon -- for AWS.

dncornholio 5y ago
Assumptions are the mother of all fuck-ups..

pron 5y ago

> Generally go with JDK 11, if you may have to deal with older software then maybe go with 8 That's a good recommendation for library authors, but if you're deploying an application that's regularly maintained, I would recommend using the most recent version -- that's the cheapest, safest way -- and if it isn't, consider an old version (like 11) with one of the LTS offerings, choosing a vendor you trust to support OpenJDK (https://news.ycombinator.com/item?id=28821316 https://news.ycombinator.com/item?id=28821316). Of course, new applications should now target 17. It's both the current version and it has LTS.