You're assuming a heavily replicated horizontally scaled service. A lot of Java servers run on one or two servers. Hardware costs are immaterial compared to people/opportunity costs.
Fact is, Java now has a reputation for pointless churn that it once didn't have. For example kicking JavaFX out of the default JDK builds makes no sense outside the world of Oracle corp politics. It would be easy to keep bundling it and would reduce the churn but instead it's now needing new gradle/maven plugins and stuff. Ditto for all the other stuff that's being kicked out.
Also people won't use incubator modules so realistically new Java's have very few new features that can justify the painful upgrade process. Some syntax sugar and better GCs. If you're CPU constrained better perf but a lot of apps aren't. They're feature constrained.
> Hardware costs are immaterial compared to people/opportunity costs.
First, the fact is that companies do care a lot about those costs, and why not have both? The early problems with the 8->9+ migrations were inevitable, as libraries became coupled to internals. There were two options: stop improving the platform, or get some short-term pain in exchange for a couple more decades at the top.
> Fact is, Java now has a reputation for pointless churn that it once didn't have.
It does have more churn than it once did, because that's what more people want. It's still significantly less churn than any other popular language/platform out there, with the exception of C.
> For example kicking JavaFX out of the default JDK builds makes no sense outside the world of Oracle corp politics. It would be easy to keep bundling it
I understand why it might appear to be easy to start bundling JavaFX with OpenJDK, but it's not. There is no one in the world more personally invested in the success of the platform than the people maintaining it, and we need to constantly choose where to put our resources. With an ecosystem so big, no matter what we do there are bound to be quite a few people who are disappointed with the budgeting, but the amazing resurgence we're seeing speaks for itself.
> Also people won't use incubator modules so realistically new Java's have very few new features that can justify the painful upgrade process.
You're entitled to that opinion, but in a few short months the majority of the ecosystem is expected to be on 11+.
JavaFX is still maintained by Oracle so I don't see how budgets are related, the JDK ships lots of modules that aren't a part of the Java SE spec, and adding it in is a simple matter of jlinking it. It would be very easy to start bundling it again.
I'm sure there's some explanation for separating it that makes sense if you're very close to things, but whatever the underlying rationale: that one move broke every JavaFX app simultaneously. JavaFX is the most modern GUI library, the one Sun/Oracle promoted for years as the replacement for Swing and yet new Java releases cannot run any old releases of any of those apps. That's what people mean when they say Java lacks backwards compatibility: their apps stop running.
Yes and no. Yes, we still have some Oracle engineers contributing, but development is co-led with Gluon, and not at the same standard of contribution as other Oracle-led OpenJDK efforts. Second, the problem isn't the actual building of the package, but the lack of desire to coordinate releases. Same goes for the EE modules -- which orders of magnitude more people use than JavaFX.
> that one move broke every JavaFX app simultaneously
> Java lacks backwards compatibility: their apps stop running.
Yes, but given that Java's backward compatibility is significantly stronger than pretty much anyone else's (except maybe C), it's important to understand that its former, even stronger form, was not so much by design, but by unfortunate necessity -- investment in the platform was low, and so the rate of change. There is simply no way to let the complexity of the JDK grow monotonically, so things have to be removed or separated. If, say, 1 in every 100 projects has to make a code change (not just include external packages) only once every few years -- we're very happy with that.
We put a very high premium on backward compatibility, certainly compared to other platforms, but it's not absolute, as that would entail stopping the platform's evolution. Especially now with the disappearance of the JRE, the addition of jlink and the move toward embedded runtimes, aiming for 100% compatibility for 100% of users is not even necessary.
>You're entitled to that opinion, but in a few short months the majority of the ecosystem is expected to be on 11+.
Ooopf.
Only way I see that being possible is if 11+ can be adopted by the ecosystem without significant rewrites of code and build scripts.
Has that situation really improved enough since the nightmare 8 to 11 migration requirements locked in most of the ecosystem on 8 for production builds and where can we read about it?
> Only way I see that being possible is if 11+ can be adopted by the ecosystem without significant rewrites of code and build scripts.
It can and it has. The only code that had to be modified is code that hacks into JDK internals, as the spec is virtually backward-compatible (the incompatible spec changes are so small as to be insignificant, except possibly the removal of some modules from the JDK that have to be changed into external dependencies, but that's a pretty simple change).
> Has that situation really improved enough since the nightmare 8 to 11 migration requirements locked in most of the ecosystem on 8 for production builds and where can we read about it?
Absolutely, because libraries that hack into JDK internals have already fixed their issues. The projection is still that by the end of this year more than half of the ecosystem will be on 11+.
Fact is, Java now has a reputation for pointless churn that it once didn't have. For example kicking JavaFX out of the default JDK builds makes no sense outside the world of Oracle corp politics. It would be easy to keep bundling it and would reduce the churn but instead it's now needing new gradle/maven plugins and stuff. Ditto for all the other stuff that's being kicked out.
Also people won't use incubator modules so realistically new Java's have very few new features that can justify the painful upgrade process. Some syntax sugar and better GCs. If you're CPU constrained better perf but a lot of apps aren't. They're feature constrained.