Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Installing Java in 2025, and Version Managers

blog.hakanserce.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Installing Java in 2025, and Version Managers

#51

Post by lmm »

Freak_NL wrote: post #36
lmm wrote: post #32

Earlier quoted context omitted.

> there will come a time when one branch will be used to test the jump from 17 to 24 or something like that, so you'll work on that, but also switch back to the master branch when a colleague needs some help there. But can you not just install 24 on your dev box and use that to work on either branch, maybe with -source/-target arguments? It never used to be a problem to develop with a newer JVM even if it was an olde…

Ideally, yes. In the real world? Nope. The longer you work one some project, the bigger the chance you will run into some edge case determined by the major version of the JDK. It just happens. Even if you do all developing on the latest LTS, you will want to be able to switch to whatever version is running on the dev or prod application servers to replicate a bug as closely as possible. By the way, you are ignoring t…

> Even if you do all developing on the latest LTS, you will want to be able to switch to whatever version is running on the dev or prod application servers to replicate a bug as closely as possible.

Occasionally, sure. But is it really frequent enough to worry about?

> By the way, you are ignoring the case I mentioned where a JDK bug happened between one minor version and the next.

I am, because I don't see why it's a case you'd worry about. Just install the version without the bug.

I mean sure, I can see some minor advantages to making it easy to change JDK versions. But for how often you want to do that, it really doesn't seem worth the overhead of having another moving part in your setup.

Re: Installing Java in 2025, and Version Managers

#52

Post by Freak_NL »

lmm wrote: post #51
Freak_NL wrote: post #36

Earlier quoted context omitted.

Ideally, yes. In the real world? Nope. The longer you work one some project, the bigger the chance you will run into some edge case determined by the major version of the JDK. It just happens. Even if you do all developing on the latest LTS, you will want to be able to switch to whatever version is running on the dev or prod application servers to replicate a bug as closely as possible. By the way, you are ignoring t…

> Even if you do all developing on the latest LTS, you will want to be able to switch to whatever version is running on the dev or prod application servers to replicate a bug as closely as possible. Occasionally, sure. But is it really frequent enough to worry about? > By the way, you are ignoring the case I mentioned where a JDK bug happened between one minor version and the next. I am, because I don't see why it's…

Just install the version without the bug? Have you never developed software in a company?

Sometimes the JDK version you are targetting cannot be changed at that time, for a variety of reasons, most beyond your control.

Sometimes the JDK contains or triggers a bug you need to workaround and test in various minor versions.

Sometimes you need to switch to the exact minor version used in production.

Often you need to switch JDKs even within a single project, more often with several projects.

In the years that I've used SDKMan the number of times I invoked it to switch JDK versions in a terminal was more than once on hundreds of days (along with hundreds of days where whatever I set it to was fine for weeks on end). All painless, quick, and easy. Why wouldn't anyone involved in developing Java in a corporate setting make life easier on themselves? Those are not 'minor advantages', those are major time and mental overhead savers. It's a trivial tool to install and maintain too with almost no overhead for me to worry about. And if it breaks? Then the last version I configured will just keep working, and I can spend maybe half an hour to set up an alternative. That hasn't happened yet, so for a tool I've been using for a decade or so, that's pretty good.

Re: Installing Java in 2025, and Version Managers

#53

Post by dig1 »

jillesvangurp wrote: post #40

Couple of points here: - Most of the JDKs mentioned are simply builds of openjdk. There are a few exceptions with alternative runtimes from e.g. IBM. But unless you have a good reaon to use those, use any OpenJDK build. They are functionally identical and the certified ones pass an extensive test suite to guarantee that. Coretto is a safe bet with long term support and backported fixes. - There's a difference between…

And don’t hesitate to use a JRE (Java Runtime Environment) if all you need is to run java/jvm applications - assuming the application doesn’t already ship with its own runtime. A JDK is roughly 140 MB, while a JRE is about 60 MB (and can be further minimized). I’ve seen installations of the full OpenJDK just to run apps, which is unnecessary in most cases.

Re: Installing Java in 2025, and Version Managers

#54

Post by layer8 »

Freak_NL wrote: post #29
jakebasile wrote: post #13

I just don't see the point in installing a version manager specifically for the JDK. It's fine to have multiple installed, and at least on Debian-likes you have the built in update-java-alternatives method to switch between them. On macOS I wrote my own 9-line Zsh function that lists the JDKs available and sets JAVA_HOME. In containers you'll never switch at all, just install whatever you want and be done with it. ET…

The update-java-alternatives tool is suitable for adjusting the JDK for everything at once, but it lacks the ease of use of something like SDKMan when you have one project stuck at Java 8 and another on 11, and another on 17, or perhaps you're testing a branch on 24, etc. Then it's just: sdk use java 11.0.29-tem And in that terminal it will use that, while another terminal happily uses a different version. That's use…

What does it do, other than presumably switching PATH and JAVA_HOME? The documentation on the website doesn’t really say.

Does it have any interaction with e.g. Maven Toolchain?

Re: Installing Java in 2025, and Version Managers

#55

Post by layer8 »

kryptiskt wrote: post #39
nathell wrote: post #26

Fortunately, the Java ecosystem isn’t JS where breakage is so common that you have to be extra careful about the version of Node you’re using. As a Clojure programmer, I have never seen a case where it mattered which vendor my JVM was coming from, and 95% of the time I don’t care which version I’m using, as long as it’s reasonably recent. For the remaining 5%, on macOS, my JVM version manager is this zsh one-liner: j…

> I have never seen a case where it mattered which vendor my JVM was coming from As I understand it, Oracle's JVMs only get free updates for a limited time. If you keep using them after that you risk getting caught in a license audit.

It’s okay to use them for development and testing, just not in production. But yes, you don’t get LTS updates.

Re: Installing Java in 2025, and Version Managers

#56

Post by layer8 »

rimmontrieu wrote: post #33

+1 sdkman! is awesome. I've been using sdkman! for a decade to manage Java installations. Doesn't seem to work on freebsd though, which I have to use freebsd's pkg instead. On Windows, the only sane way to install Java seems to be scoop.sh or chocolatey

JDKs are just a directory tree. Not sure what you mean on Windows, you simply unpack the JDKs to whatever directories you want, and set PATH and/or JAVA_HOME according to which you want to use, and/or switch them in your IDE.

Re: Installing Java in 2025, and Version Managers

#57

Post by lervag »

jolux wrote: post #11

pro tip: don't bother with SDKMAN. use https://mise.jdx.dev to install Java, it can also install a bunch of other languages and tools. it's most likely the last tool version manager you'll ever need.

I'll vouch for that - mise is awesome and replaces both sdkman, pyenv, and other similar tools that are restricted to one ecosystem.

Re: Installing Java in 2025, and Version Managers

#58

Post by rimmontrieu »

layer8 wrote: post #56
rimmontrieu wrote: post #33

+1 sdkman! is awesome. I've been using sdkman! for a decade to manage Java installations. Doesn't seem to work on freebsd though, which I have to use freebsd's pkg instead. On Windows, the only sane way to install Java seems to be scoop.sh or chocolatey

JDKs are just a directory tree. Not sure what you mean on Windows, you simply unpack the JDKs to whatever directories you want, and set PATH and/or JAVA_HOME according to which you want to use, and/or switch them in your IDE.

The advantage of using a package manager like scoop or chocolatey is that you have a unified interface to manage multiple versions of JDK, and you can switch the default version system-wide on the fly, regardless of your IDE:

  scoop bucket add java

  # Install JDK 11
  scoop install java/temurin11-jdk
  # Install JDK 17
  scoop install java/temurin17-jdk
  # Use JDK 11
  scoop reset temurin11-jdk
  # Use JDK 17
  scoop reset temurin17-jdk
I also wrote a short guide on my website: https://raizensoft.com/tutorial/install-java-gamedev/

Re: Installing Java in 2025, and Version Managers

#59

Post by nurettin »

pjmlp wrote: post #49
nurettin wrote: post #47

Earlier quoted context omitted.

> multiple vendors has always been a thing in Java since the early 2000's. Early 2000s? There was usually one language version that circulated. We had the blackdown java on debian, whatever version sun hosted (1.3?) and something IBM made which was probably on a password protected ftp site available to corporate clients. And it was like that for years. Now there's like 10 vendors supporting 3-5 different major langua…

Yes, doesn't matter if it was commercial or not, or what operating systems. We are not talking about what was available only to GNU/Linux folks as free beer.

If you're going to pick some words and gloss over the rest, just don't respond.

Re: Installing Java in 2025, and Version Managers

#60

Post by pjmlp »

nurettin wrote: post #59
pjmlp wrote: post #49

Earlier quoted context omitted.

Yes, doesn't matter if it was commercial or not, or what operating systems. We are not talking about what was available only to GNU/Linux folks as free beer.

If you're going to pick some words and gloss over the rest, just don't respond.

If you are going to ignore Java's market adoption history since its introduction in 1996, just don't bother.
Post reply on HN