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

41–50 of 65 posts

Re: Installing Java in 2025, and Version Managers

#41

Post by oweiler »

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…

You can also check in an .sdkmanrc into each respective project which defines the required Java version.

Then SDKMAN! will perform the switch automatically when you enter the directory.

https://sdkman.io/usage/#env-command

Re: Installing Java in 2025, and Version Managers

#42

Post by yardstick »

lmm wrote: post #32
Freak_NL wrote: post #31

Earlier quoted context omitted.

It's not only normal, it is completely to be expected. Even if you have only one project, 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. sdk use java xxx And done. A new LTS is released? Just sdk install it. Set the one you use most as default, and focus…

> 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…

Note: Java compiler versions from 9 onwards have lost the ability to -target 1.5 and earlier.

Sometimes you still need Java 8 to compile for super old programs — think decades old IoT devices too small to handle newer JVMs that you still need to do the occasional minor update for.

But really sdkman is just nice to be able to quickly install and quickly switch jvms without worrying about any opinions the os package manager may have. If I want an old jre8, do I need to fuss around with finding the right package repo for my arch etc, or should I just use sdkman and be done with it.

Re: Installing Java in 2025, and Version Managers

#44

Post by skylurk »

Coming from Python, I get the feeling Java tooling is ripe for an astral-shaped astroid.

Am I just a Java rookie, or would Java benefit from equivalents for Python's ruff/uv/ty?

Obviously, lots of tooling already exists (Python's did too). But distilling all the lore and xml into a handful of fast opinionated cli tools seems useful to me anyway.

Re: Installing Java in 2025, and Version Managers

#46

Post by nurettin »

skylurk wrote: post #44

Coming from Python, I get the feeling Java tooling is ripe for an astral-shaped astroid. Am I just a Java rookie, or would Java benefit from equivalents for Python's ruff/uv/ty? Obviously, lots of tooling already exists (Python's did too). But distilling all the lore and xml into a handful of fast opinionated cli tools seems useful to me anyway.

I remember manually choosing dependencies by pasting them from maven to pom.xml and jetbrains IDE kindly nudged me every day to keep up to date whenever newer versions were available. Version massaging took a large portion of the day because I was too autistic to ignore a yellow alert.

Re: Installing Java in 2025, and Version Managers

#47

Post by nurettin »

pjmlp wrote: post #16

I don't get the point. First of all, multiple vendors has always been a thing in Java since the early 2000's. Second, configuring a couple of environment variables isn't that much of a challenge. Third, all IDEs have an option to use a bundled JVM, and allow for JVM selection per project. Finally, for applications the modern way is to build the runtime alongside the application, or AOT compilation.

> 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 language versions that change every few months.

Re: Installing Java in 2025, and Version Managers

#48

Post by figmert »

wiradikusuma wrote: post #37
figmert wrote: post #14

Earlier quoted context omitted.

I'd skip that and use mise. It's an asdf compatible manager and does so much more. It manages scripts (replacing make), environment variables and it's super fast.

I have a feeling somebody will link that xkcd post soon...

Perhaps. But I wouldn't be so sure. It has functionality to replace the following tools:

- make (via its tasks feature)

- direnv (via its environments features)

- Just about most package managers (via it's dev tools features)

It has backends for just about anything (aqua, cargo, asdf, gem, github, go, etc).

It allows for locking your tooling similar to a package.json lock file.

And the nice thing is that it does it a lot better those tools (I recently found out make gobbles up any error codes and returns 2).

Re: Installing Java in 2025, and Version Managers

#49

Post by pjmlp »

nurettin wrote: post #47
pjmlp wrote: post #16

I don't get the point. First of all, multiple vendors has always been a thing in Java since the early 2000's. Second, configuring a couple of environment variables isn't that much of a challenge. Third, all IDEs have an option to use a bundled JVM, and allow for JVM selection per project. Finally, for applications the modern way is to build the runtime alongside the application, or AOT compilation.

> 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.

Re: Installing Java in 2025, and Version Managers

#50

Post by cess11 »

That's a lot of words to promote SDKMan.

Picking a JDK is simple. You pick the latest Temurin LTS. It'll work, and if it doesn't, grab the Zulu with JavaFX already plugged in or suss out the incantation for implanting it into your Temurin through web search.

Besides JDK management SDKMan also provides an easy to understand interface for toolchains for things like Clojure and Kotlin and also stuff such as Quarkus.

Post reply on HN