61–65 of 65 posts
Ever since I found `asdf`, I threw away jenv, nvm, fmn and rvm.
I used asdf for a while but moved to mise-en-place (mise). Same reasons though, one tool manager for all the tools.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 temurin1…
Earlier quoted context omitted.
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 temurin1…
Thanks, but what does “the default version system-wide” mean, other than setting environment variables or replacing the JDK in a fixed location?
With scoop you can just launch the terminal and run `scoop reset [java-version]`
Earlier quoted context omitted.
> 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 swi…
If you're running x.0.3 in production, you'd run x.0.3 locally. If there's a JVM bug that your application hits on x.0.3, either it's a showstopper in which case you'll find a way to upgrade/fix production quickly, or it's something you can tolerate, in which case you can tolerate it in local dev too. If you decide it's time to upgrade to x.0.4, you'd upgrade to x.0.4 locally, test a bit, then upgrade to x.0.4 in production. What's the scenario where you need to keep switching between x.0.3 and x.0.4 locally? You upgraded application Y to x.0.4, then discovered that application Z hits a showstopper bug and needs to stay on x.0.3? That's not a situation that you let fester for months, you either fix or work around the bug pretty quickly, or you decide that x.0.4 is too buggy and put everything back to x.0.3, and for that short period sure theoretically you would want to develop application Y under x.0.4 but the risk of developing it under x.0.3 is pretty damn small.
I get the argument that the cost is pretty low. It's just this is addressing something that really doesn't feel like a problem for me, and something that I don't think should be acceptable for it to be a problem. The JVM always used to be something you could upgrade almost fearlessly, and I think there was a lot of value in that.