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

31–40 of 65 posts

Re: Installing Java in 2025, and Version Managers

#31

Post by Freak_NL »

vladgur wrote: post #25
lmm wrote: post #20

Earlier quoted context omitted.

OK but again what's the use case for that? Can you not just use a new version of Java for all your projects, at most setting -source/-target in your project configuration? Certainly in the old days it was always backwards compatible, at least enough that you could develop under a current version and maybe just have a CI job to check that your code still worked on old versions.

In a large organization with hundreds of business-critical Java applications you can bring them all up to one version at once. It’s quite normal to have multiple versions of JDK being used by different applications

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 on the project instead of managing JDKs.

Oh, and very occasionally you'll actually get hit by a bug within one Java major version (like when they removed historic offsets from the timezone database included in the JVM, that was fun). At that point being able to switch between minor versions easily is quite nice.

Re: Installing Java in 2025, and Version Managers

#32

Post by lmm »

Freak_NL wrote: post #31
vladgur wrote: post #25

Earlier quoted context omitted.

In a large organization with hundreds of business-critical Java applications you can bring them all up to one version at once. It’s quite normal to have multiple versions of JDK being used by different applications

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

Re: Installing Java in 2025, and Version Managers

#34

Post by krzyk »

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…

direnv is great for switching any envnvariables let given directory.

I use it when I have projects with different jdks or nodejs.

Re: Installing Java in 2025, and Version Managers

#35

Post by krzyk »

Zardoz84 wrote: post #28
orthoxerox wrote: post #23

Earlier quoted context omitted.

Yes, I have a dead-simple env.bat/env.sh file that sets up specific Java and Maven versions for programs that IDEs struggle with building. I don't see the need to set up an extra tool to install more Java versions, because I don't rebuild my dev environments from scratch every week. My Java 8 installation is three-years old now and has survived a complete Windows reinstallation.

Good luck when you sysadmin apply a decent automated security suite and removes the old Java 8 installation because isn't updated

If sysadmins do that then you have bigger problems than just disappearing jdks. Run.

Re: Installing Java in 2025, and Version Managers

#36

Post by Freak_NL »

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…

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 the case I mentioned where a JDK bug happened between one minor version and the next.

Re: Installing Java in 2025, and Version Managers

#37

Post by wiradikusuma »

figmert wrote: post #14
wiradikusuma wrote: post #9

Before even deciding which Java to install, you have to decide which _version managers_ to use: 1. No version manager, download and install manually. Not that hard, since it's just a zip file and maybe set JAVA_HOME envvar. If you need multiple versions to co-exist, skip this. 2. Use OS' "native" package manager. Brew, apt, chocolatey. 3. Generic package manager like asdf. 4. SDKMAN!, JBang, jEnv, jabba... Deciding i…

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

Re: Installing Java in 2025, and Version Managers

#39

Post by kryptiskt »

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.

Re: Installing Java in 2025, and Version Managers

#40

Post by jillesvangurp »

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 developers and production usage here. Tools like sdk man are for developers that need to switch between specific versions in different projects. You see the same in the python, ruby, js, etc. world. System wide installations aren't that useful. Unlike many of those, project dependencies are never system wide. There's no global installation of Java dependencies.

- Avoid Oracle's builds unless you need them for compliance reasons. Their licensing can get expensive and they are famously pretty aggressive on enforcing terms. There is no functional advantage to using their builds. They aren't faster or better in any way. There is no Oracle specific secret sauce.

- If you are on Linux or mac, getting your sdk via your favorite package manager is fine for casual use. Just be aware that this might not necessarily work with all software projects you want to work on. If that matters to you, that's what sdkman is for.

- JDKs take up a lot of space. A lot of tools are trigger happy to add JDKs but don't necessarily remove them. Tracking down and removing redundant JDKs is something I have to do regularly. Some tools try to be a bit too smart and will ignore the presence of perfectly good jdks I have installed with sdkman (e.g. intellij).

- Use containers for deployment and pick the right base image. You should not need server side jdk installations unless you are doing things the old school way.

Post reply on HN