It's really handy for switching between projects that are on different Java versions, plus tools like IntelliJ pick up on the correct version via the SDKMAN! configuration as well.
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.
> 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.
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.
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.
> 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.
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.
I've hit JVM bugs in my professional career, sure. I just don't see the scenario where you'd need to be switching back and forth more than occasionally.
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.
I've been lucky enough that the large organisations I worked for generally had policies and enforcement to ensure that all applications were kept current. It's more initial effort but it pays dividends.
But even if you don't have that, most people work on at most a handful of apps at a time, and again I would defer checking against a specific version to CI most of the time rather than switching around which JVM I'm using locally, unless your code was very tightly coupled to JVM internals somehow.
So far I am 0/2 on buying IODD devices and having them fail within a couple of weeks. I gave it a good 5 years between purchases and bought a different version of the unit. Perhaps I just have extremely bad luck, but my experience is that basically anything is more perfect than an IODD.
On my ThinkPad T430, I have a weekly full discharge cycle set up using "tlp recalibrate BAT0", it helps avoid that issue and helps confirm that the battery is still functional.
Hello, author here! It's a nice surprise to notice my own post here, but the timing is unfortunate as I'm shuffling things around on my home server and will accidentally/intentionally take it offline for a bit.
I have considered going that route, but I'd have to switch to a platform that supports those formats and that will likely be too expensive for me as a hobbyist.
> You’re not just writing for today’s invisible audience. You’re writing for:
> Future you. Your posts become a time capsule of your evolving mind.
Fully agree with that one. My own blog has become a public diary of my hobby and it's great to see what I've been up to and how wrong I was about certain predictions and assumptions, especially about the ones that say that I'm done reworking my home server setup, multiple times.
> availability of operating system upgrades [..] at least 5 years from the date of the end of placement on the market of the last unit of a product model
would be nice if the EU would mandate something like lineage os being available from day 1 for a device. manufacturer would have to provide resources to make sure it works before release.
I wish EU at least make mandate that from the moment someone stop providing security updates they have to provide some key to unlock bootloader etc and even for those iPhone that are not supported anymore. Those devices like e.g. iPhone X are still super powerful and they could be used for other purposes if we could install linux on them. They could be a much powerful version or raspberry pi with nicer form but with touchscreen, gps, 4g, wifi, bluetooth, cameras, microphones, imu, speakers, battery, audiojack/connector.
Devices? Yes. Expensive? Only if you fail in picking them. Buy an iPhone or something. I'm in Android camp, but I only buy flagships (after some bad experiences with cheap end of the phone spectrum) specifically because I can rely on them to work for 3+ years, getting updates over that period, and importantly, still being performant enough relative to contemporary software as to not be annoying to use.
I agree with GP here. In the current security-obsessed zeitgeist, 2 years of security updates is criminally low, pretty much designed to generate e-waste.
Something like a Samsung A55 will also get 5 years of security updates. This line usually converges to around 300 Euros halfway the yearly product release cycle. There are cheaper Samsung models with long support periods, but last time I looked, they would only get quarterly security updates. The Pixel _a_ line usually also has pretty good pricing, but they tend to have weird issues/bugs.
(I'm an iPhone user, but just to point out that there are also more affordable options with longer support periods.)
In my experience, I had to give about 100/yr to havea relatively good device foor my needs. I could choose to buy a cheap thing every year, or 600 every 6; for similar Performance. I prefer to change device no so often. 2 years is just too short.
iPhones have very good resale value even after 3 years, financially not that expensive! Easily good for 5 years and even then you can have decent money for it. Of course they can become pretty expensive suddenly - just when you drop them.
There is a middle ground. I spent $94 total after taxes/fees getting a Pixel 6A in August 2023. Its security updates end-of-life is July 2027. That's 4 years of security updates for only $23 more (assuming the £59 is taxes and fees included) and my pixel 6a specs blow this thing out of the water.
It was right around the time they started phasing out the pixel 6a (stores no longer stocking new 6a) and a deal for it came up on a popular deal forum with the abbreviation "SD". (I don't want to link to the site because I think at least half the content is ads and other sponsored content).
It seems like a valid metric to pick on. Premium devices are refreshed early/short cycle their lifespans because they are purchased by customers with disposable income. Budget devices should be sold to last as that's what's important to the customers buying them.
As a counter though, I would say with 2gb of ram this device just won't be fast enough for most of its users in 3 years anyway; so although I find this a valid argument to make, a new issue pops up immediately (for me at least).
I have also run into issues with DFS in the past[0] without fully understanding what was wrong, until my friend let me know that this is a thing. Choosing a static Wi-Fi channel that's outside the DFS range, or limiting the selection of channels to exclude the DFS channels has worked well for me.
Presuming you visit this site often, doesn’t this indicate to you that their case is perhaps overstated? From what I understand, the activity they’re talking about on HN is just comments, often in a [dead]ed thread, so they’re things one can simply choose not to engage with.
HN is a relatively diverse community; for every example of a hate comment there are dozens of more constructive comments, including those calling out the hater. There’s no special protection given to trash commenters. They’re often banned, sometimes even publicly called out.
Related, these comments caused me to discover Kiwi Farms. If you want to see a place that sounds like what is described in marcan’s letter, check that place out. That is absolutely a trash forum for trash people. Blocking HN traffic isn’t going to protect them from that sort. Indeed, thick skin and the willingness to put down their phone will protect them from that sort.
I heard a saying recently that went along the lines of "engineering without constraints isn't engineering", and after reading "The Performance Inequality Gap"[0] and its follow-up series "Reckoning"[1], I'm convinced that software developers should use lower end devices so that they, too, feel the pain they're inflicting on others.
Running cheap hardware is fun and will make you want to improve your craft.
You should be testing your software on the typical device it will run on. It's just good engineering to do so. If you have to eBay a bog-standard laptop to do this, do it.
Developing software on the average potato device? Hell no. What a waste of time.
