In 2020 I became a full time Java developer, coming from a infrastructure role where I kind of dealt with Java code, but always as artifacts I managed in application servers and whatnot.
So when I first started dealing with the actual code, it scared me that the standard json library was basically in maintenance mode for some years back then. The standard unit test framework and lot of other key pieces too.
I interpreted that as “Java is dying”. But 6 years later I understand: they were are feature complete. And fast as hell, and god knows how many corner cases covered. They were in problem-solved, 1-in-a-billion-edge-cases-covered feature complete state.
Not abandoned or neglected, patches are incorpored in days or hours. Just… stable.
All is quiet now, they are used by millions, but remain stable. Not perfect, but their defects dependable by many. Their known bugs now features.
But it seems that no one truly want that. We want the shiny things. We wrote the same frameworks in Java, then python the go then node the JavaScript the typescript.
There must be something inherently human about changing and rewriting things.
There is indeed change in the Java ecosystem, but people just choose another name and move on. JUnit, the battle tested unit testing framework, had a lot to learn from new ways of doing, like pytest. Instead of perturbing the stableness, they just choose another name, JUnit5 and moved on.
> But it seems that no one truly want that. We want the shiny things. We wrote the same frameworks in Java, then python the go then node the JavaScript the typescript.
I think that people are just afraid that if they use a library in maintenance, they will run into a bug and it'll never get fixed. So they figure it's safer to adopt something undergoing further development, because then if there are issues they will get fixed. And of course, some people have to deal with compliance requirements which force them to only use software which is still updated.
I think there's a huge "it depends" caveat. In the JS world I remember browserify, it did what it was meant to do and it was extendable. A really nice Unix-like minimal software.
The reality is that it was just a small piece in a larger ideal build chain. So for the past 10+ years, we've seen an explosion of more complete build tools that do everything.
Browserify now sits there "finished" and receiving bugfixes. Nobody uses it anymore, even if it popularized npm for the frontend.
I remember we made a switch to redis because java's memcached library was unmaintained. I made I joke that it's just feature-complete and cannot be improved upon, people chuckled, but we still did the switch.
Quite a bit of risk telescoping there...because you had the source code to the memcached library so in the theoretical case you found a bug in mature code (how many times have you seen that?), you weren't SOL. So instead you switched to an entirely new system? If you were trying to minimize risk and cost, you did the opposite unless memcached was doing something else that was a problem.
It wasn't entirely just that, we had to switch to redis for another sub-system and IIRC there some positive implication for cache layer as well. It's been awhile it wasn't just because memcached libary was unmaintained.
Honestly having looked at the memcached clients available for Java recently, I don't think any of the options could be considered feature-complete. None of the main ones support the meta protocol at all, meaning most of the advanced features aren't possible (and these are things that can't be emulated on the client side).
Hell, the main feature I needed (bulk CAS get) didn't even require the meta protocol or recent memcached features - spymemcached just never bothered to implement it. I ended up abandoning the change I was working on, because the upstream never looked at my PR and it wasn't worth forking over (bigco bureaucracy etc).
There are also quite a few legitimate bugs open for years that haven't had so much as a comment from maintainers.
So when I first started dealing with the actual code, it scared me that the standard json library was basically in maintenance mode for some years back then. The standard unit test framework and lot of other key pieces too.
I interpreted that as “Java is dying”. But 6 years later I understand: they were are feature complete. And fast as hell, and god knows how many corner cases covered. They were in problem-solved, 1-in-a-billion-edge-cases-covered feature complete state.
Not abandoned or neglected, patches are incorpored in days or hours. Just… stable.
All is quiet now, they are used by millions, but remain stable. Not perfect, but their defects dependable by many. Their known bugs now features.
But it seems that no one truly want that. We want the shiny things. We wrote the same frameworks in Java, then python the go then node the JavaScript the typescript.
There must be something inherently human about changing and rewriting things.
There is indeed change in the Java ecosystem, but people just choose another name and move on. JUnit, the battle tested unit testing framework, had a lot to learn from new ways of doing, like pytest. Instead of perturbing the stableness, they just choose another name, JUnit5 and moved on.