At my last job, we only used LTS in production. Upgrading Java was always a long process, but that's more due a legacy monolithic app across thousands of servers.
You can almost think of the LTS releases as a major release and the non-LTS as a minor release, so really this could be 25.2. The current Java release schedule is to maintain a consistent and predictable release cadence instead of pushing big new features every 6 months.
For a Seiko, I'll also recommend https://www.theseikologist.com/. As his name suggests, he specializes in Seikos and has a large stock of vintage Seiko parts which are hard to source. Though, it's still not cheap. I have a broken Seiko chronograph from the 70s and he quoted $500 to just do the watch equivalent of a tune up. He can't give a better estimate without opening it up, which is understandable.
If it isn't a hardship, I do recommend fixing your dad's watch. Sentimental pieces are always special.
Have you had issues with the .jhw TLD on Apple devices? I have my own DNS for my homelab with CoreDNS with house.hill as my domain. My house is on a hill. But .hill is not a TLD, and both my macbook and iphone stopped resolving it quite a while ago.
No. Both MacOS and iOS happily resolve and connect to the machines in my homelab.jhw domain. I did add the root cert of my CA (Certificate Authority) to the trust store on MacOS and iOS, so I can also enjoy TLS connections. Scroll to the "Add the certificate" part of https://jan.wildeboer.net/2025/08/Create-SMIME-Cert-stepca/ for the HOWTO that worked for me.
If you have Advanced Tracking and Fingerprinting Protection enabled for Safari, it will ignore your system resolver. iCloud Private Relay also ignores it unless DNS is set using configuration profiles.
That generally suggests they’re not pointing at the resolver you have set to handle that domain. Otherwise your apple devices can’t tell a valid TLD from an invalid one: they just launch the DNS lookup and let the server tell them.
The exception to this is .local, which you shouldn’t use for internal systems because it will confuse the heck out of them in weird ways, because .local is by RFC not meant to be used in that way.
Think of uv more as like npm or other thing like that. The new Python pyproject.toml is similar package.json. It defines the project description, list of dependencies, and other hooks. Uv is a package/project tool using pyproject.toml. It is easy to manage dependencies, build and publish to PyPi, add hooks to run tests, linters, or whatever, again much like package.json. It also manages the virtualenv automatically, though you can manage it yourself.
Equating a frustrating anti-pattern of websites with medical equipment failure is extremely disingenuous. An infusion pump failure can harm a person, and according to the article, has seriously injured at least on person. Hijacking the back button isn't going to physically harm someone.
Well excuse me for being extremely disingenuous then. But the no harm argument is arguable incorrect, I myself might get a heart attack some day because of a dark pattern given how infuriating those things can be.
Streams (FP in java) is slower than for loops for a couple reasons. A big one is java doesn't natively support real closures or lambdas. It does have syntax for them, but that is just syntactic sugar for an class with a single method under the hood. So streams end up doing lot of object allocation and garbage for the fake closures.
Also, streams operate on objects, so they have to be on the heap. You can't use them with primitives on the stack. Though with autoboxing, the JVM may play some tricks with a list of Integer objects really being primitives on the stack, but I would never count on it.
As for SIMD, Java isn't going to parallelize anything automatically. You need to tell it you run the steam in parallel which will split it into threads. Java doesn't have lightweight threads like coroutines.
I know lightweight threads are on the roadmap and maybe available in Java 21 or newer. I know real closures have been considered, but I don't if it's gone anywhere. It's hard to do a quick search because we got "closures" in Java 8 so theres a lot of noise.
And as a caveat, I am most familiar with Java 17 (and older). I expect we'll look at moving to Java 21 (current LTS) next year.
The big differences are:
1. Rust closures are by-value structs; whereas Java closures are heap objects.
2. Rust generics are monomorphized; whereas Java type-erases them -> lots of virtual call overhead when passing a closure to a generic function.
Sometimes, if the Java JIT manages to inline absolutely everything, it can optimize away these overheads. But in practice, Rust FP gets optimized a lot more reliably than Java FP.
The other problem with the parallel streams is that it’s badly implemented. Threads for parallel streams are pulled from a single thread pool shared across the whole application so if you have multiple parallel streams in an application that’s already inherently multithreaded (e.g. a web service), you end up with severe resource contention that makes the parallelism work poorly if at all and can end up causing your app to deadlock because all the threads are in use somewhere else. There’s a workaround for it, but it ends up requiring some ugly boilerplate code to work.
> It does have syntax for them, but that is just syntactic sugar for an class with a single method under the hood. So streams end up doing lot of object allocation and garbage for the fake closures.
In Rust a closure is really just a struct that implements up to three closure traits, each of which provide a single function. So from that side of things, what Java is doing for them isn't inherently different from Rust.
I believe the LLV line was only suppose to be in service for 20 years, but the government gonna government and not find a replacement till it's almost too late. So yes it was a lot of scrounging and probably a lot of USPS mechanics needing to be creative, but the LLV lasted twice as long as it was designed for. I expect this same conversation will happen again in another 40 years.
> the government gonna government and not find a replacement till it's almost too late
Actually they were going to convert to EVs back in 2006 when Bush stepped in to prevent that and punish them on behalf of his oil buddies with the Postal Accountability and Enhancement Act. The problem isn't government, it's politicians voted in to destroy it in favor of corporate interests.
> According to Tom Davis, the Bush administration threatened to veto the legislation unless they added the provision regarding funding the employee benefits in advance with the objective of using that money to reduce the federal deficit.
Bush was responsible for the provision that kneecapped USPS to prevent them from ever funding their EV ambitions (until Biden funded NGDV in 2022)
Any snarkiness aside, the point is that "the government" isn't a monolithic entity that operates inevitably or deterministically. There can be significantly different outcomes depending on who is elected to run it (and you might even have an outsized say in who that is, depending on the state you live in and whether you vote).
> Four variants of the NGDV are expected to be in fleet use: both gasoline-powered and battery-electric, in either front wheel drive or all wheel drive.
So I expect the front hood is for the gas powered engine for those variants. Further down, it talks about only 10% will be EV at the start due to cost. Also, this is in partnership with Ford so the ICE power train is the from the Ford Transit van.
All the Jetbrains IDEs have their own custom linter. It's pretty good, but my complaint has always been the inability to use it in CI/CD and to generate reports. The way I read this, they pulled their custom linter out of the IDEs and made it a standalone tool that can be added to CI/CD, which is great.
I spent a couple weeks planning a LFS install about 20 years ago. I then didn't have time to look at it all for about year, so I never went through with it. But I still learned a lot just documenting all steps and preparing with the worse case of not having decent internet if something went wrong.
You can almost think of the LTS releases as a major release and the non-LTS as a minor release, so really this could be 25.2. The current Java release schedule is to maintain a consistent and predictable release cadence instead of pushing big new features every 6 months.
reply