We (finally) upgraded last year from 8 to 17. Lots of nice things, I’m so glad we were finally able to. But it was a big project due to some dependencies and how some things were done internally.
I can’t wait for 21, but I’m not sure when we’ll switch. At least it will be trivial compared to leaving 8.
I am not sure why this is a problem. Looking at the organization of the resources directory of every project I've ever worked on, I am not sure I want more opportunity for physical and logical concepts to unnecessarily diverge.
Yeah, I do like my IDE doing the tedious work for me. It's also really nice to unzip any JAR I need to troubleshoot and know exactly where to navigate to find exactly the file with the code I need.
I like Golang a lot but the standardisation and verbosity in Java-land has some benefits after you get used to it enough to learn to ignore the boilerplate, it's pretty good to have some kind of consistency enforced by the VM when working in large codebases.
Then you’d be thrilled to hear about all the stuff your NVME drivers are doing in the background without you knowing shit about it. Or maybe you prefer to engrave your ones and zeroes in stone by hand?
Abstractions exist for a reason. In Java, that abstraction is coding in classes and packages, not files of text.
Depends- one of the hardest parts of the 11-20 upgrade for us was that cms gc was removed.
If you run a bunch of different microservices with distinct allocation profiles, all with high allocation pressure and performance constraints, and you've accomplished this w/ the help of a very fine-tuned CMS setup, migrating that over to G1/ZGC is non-trivial
Java sort of suck for microservices (microservices suck on their own) as it has relatively high bootstrap cost.
High allocation rate feels weird with micro services - I suppose that depends a lot on the coding style. G1GC is meant for generally large setups, with several cores at least. E.g. the default setup of 2048 areas on 2GB heap means, allocations over 1MB require special care.
I can't help but think if you're teetering on a knife's edge, only holding on thanks to hyper tuned GC params, then you should take a step back and consider getting out of that predicament.
Yup. We've clearly benefitted- G1 and generational ZGC have large advantages over CMS- but it's a lot of experimentation and trial-and-error to get there, whereas other deprecations/removals are usually easier to resolve.
Isn't the default config correct for pretty much all workloads, unless you have very special requirements? Like, at most one should just change the target max pause time in case of G1, depending on whether they prefer better throughput at the price of worse latency, or the reverse.
It's more likely that there's some dependency that is not easy to upgrade, because the upgrade also includes api changes (from the dependency, not from the jdk).
Compound this with multiple dependencies that exhibit this issue. If you have a "legacy" application that does not require active development, there's zero business incentive to invest into the upgrade. Unless you could prove value in having the upgrade, it just doesn't get prioritized.
Java has in recent times actually removed some apis from the standard library, and made some inaccessible (undocumented internal apis especially) so any advanced frameworks that use them would have been affected.
