FRESH

Hacker News

Home

Installing Java in 2025, and Version Managers

49 points by hakanserce

by jillesvangurp

1 subcomments

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.

by jakebasile

1 subcomments

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.
ETA: I see in another comment someone said this doesn't work for things that aren't OpenJDK. But I've yet to run into a situation where I'd want to install anything except OpenJDK. That said, I think update-java-alternatives would work with them if they provide deb files to install themselves.

by jolux

2 subcomments

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.

by lihaoyi

0 subcomment

With Mill build tool that I'm working on, you don't need to install Java at all! (https://mill-build.org/blog/16-zero-setup.html). Instead, it gets bootstrapped automatically when you launch the `./mill` script like any other third-party dependency. You can use any version you want just by editing the config file and it'll be downloaded and cached on demand. You can also configure different JVM versions to use in different Java modules without worrying about conflicts between them.
You don't need to globally install Apache-Commons, nor is there a "Apache Commons Version Manager" that you need to first install to then manage your different versions of Apache Commons. So why should the JVM need such a thing? Well with Mill, it doesn't

by pdevr

1 subcomments

I use version managers for Python, Node, Ruby, and others. But for Java, none. I have all the recent versions of Java on my Linux and Windows devices. I download the zip and extract it to a common directory "Java". Setting the path within IDEs is easy, and is mostly unavoidable (regardless of a version manager). Running standalone programs is not that complicated too.

by rimmontrieu

1 subcomments

+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

by nathell

1 subcomments

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:
```
    jvm () { export JAVA_HOME=`/usr/libexec/java_home -v $1`; }
```

by wiradikusuma

2 subcomments

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 is easy. But remembering which one you used 6 months ago when you want to install another version...

by pjmlp

1 subcomments

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.

by guidedlight

0 subcomment

From what I’ve seen is most organisations have moved to Amazon Corretto, and stuck with it.
It’s TCK-certified, supported by Amazon, and completely free.
So I don’t see the need to use any other distribution, unless it is for a niche requirement.

by genzer

1 subcomments

Ever since I found `asdf`, I threw away jenv, nvm, fmn and rvm.

by skylurk

1 subcomments

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.

by tomaytotomato

0 subcomment

I would say as well as using SDKMan, you should use Jenv shell plugin to easily manage your JDK versions across projects.
https://github.com/jenv/jenv
All you have to do is link your SDKMan binaries with Jenv and you can easily switch with one command.

by humanfromearth9

0 subcomment

There's nothing like direnv + nix + a flake with the appropriate dev shell config... And seriously, any LLM can write the .envrc, nix.conf, flake.nix files if it's too complicated.

by dboreham

1 subcomments

Happy sdkman user for many years.

by zokier

0 subcomment

Or just `apt install default-jdk-headless` and move on with your life

0 subcomment

by zelos

0 subcomment

There's always Gradle Toolchains as well, which allows you to put the JDK configuration in the branch next to the source code.

by wwarner

0 subcomment

The version manager approach feels like a giant step backward to me. Manage dependencies with containers.

by cess11

0 subcomment

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.

by wetpaws

0 subcomment

[dead]