> Traded throughput away for smaller lookup tables.
Much of the improvement came from a re-encoding of String (no longer internally encoded as UTF-16), and more sophisticated GC algorithms.
> If the jvm cant run a day without creating a hcrash report and you need 10 times as many cpus to complete a job in the same time, how is that a step forward?
If you see crashes, submit a bug report, but we've not been seeing any increase in crash reports. It's possible that you're using a library that hacks into JDK internals and is a cause of such problems. Try using JDK 16 or 17, where strong encapsulation is turned on (at least by default).
Those crashes were just on our unit tests, creating linking and destroying large volumes of objects, throwing them in a thread for some basic compute then writing results to disk. I agree its really about the gc, but the new ones just never seemed to beat the setup we have on 8, and there is only so much time that can be devoted to making things that work, work on "new shiney".
java after 8 is just mayhem, before it was easy, oracle for some things, ibm for others.
now there are new long term releases faster than we can test them, they fail at least one of the unit tests that all pass on 8, and openjdk is missing half the really nice stuff that was once free.
>submit a bug report
but to who and under what title? Oracle, IBM, openjdk?
e.g. "none of the corba stuff works anymore because its not part of 'new java'" is whose fault?
If you see crashes -- report them; they're either bugs in the JDK or possibly the result of a library you're using that employs native code or Unsafe in a way that depends on a JDK 8 implementation detail. Overall, there has not been any increase in reported crashes since 8.
> but to who and under what title? Oracle, IBM, openjdk?
The most popular Java implementation by far -- the one that serves as the basis for almost all distributions except IBM's -- is called OpenJDK, and is lead by Oracle, with contributions from Red Hat, Intel, Google, Amazon and others. You report the bug to whomever you get your JDK from, and they report it to the OpenJDK project.
> e.g. "none of the corba stuff works anymore because its not part of 'new java'" is whose fault?
CORBA works fine, it's just not distributed as part of the JDK anymore. Like most decisions around OpenJDK and the Java spec, it was made by Oracle-employed engineers (like myself), and signed off by representatives of other companies. The reasoning is that it would do more good for more people if the core team behind OpenJDK would spend their efforts on things other than maintaining CORBA, and the reaction from the community has been positive.
How to get from that to a (useful) bug report of what broke after 25 hours uptime in the newer jvm, tried most I found, openjdk, oracle, IBM before running out of time.
Which reminds me that the migration cost estimate came in at 7 figures for no clear benefits. Decision after that was to keep running on what we have working and watch for how ruby/rust/go etc develop.
We had actually _just_ started a javaFX project only a few weeks before finding out it was removed. That project was binned and we went over to android apps instead.
In fact looking at the schedule, almost all new projects are Android based now - all the old code (that still compiles) works fine there and google have amazing instrumentation for when consumer side stuff breaks.
> Which reminds me that the migration cost estimate came in at 7 figures for no clear benefits.
Most companies report a ~10% reduction in hardware costs, and more than make up for any migration costs (which are quite low these days) in under a year. See this experience from LinkedIn: https://channel9.msdn.com/Events/Java/JDConf-2020/Java-11-Jo...
In other words, the benefits are usually significant savings, even if you don't use any new features.
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+.
Similar enough code block in that to what I just described to see there is now/still a known issue in java 17 to kill services after a prolonged period of time.
There's no shortage of those hs_err files, deleted a few thousand a while ago when I found out they were the reason a staging server had run out of disk space.
> Similar enough code block in that to what I just described to see there is now/still a known issue in java 17 to kill services after a prolonged period of time.
That's a crash going back to 8, which 17 is actually reported to reduce (i.e. 17 crashes less than 8 under those circumstances). But, as you can see, when such crashes are reported, they are investigated in depth.
Its one example of issues that never should have made it into a release in the first place of any software that cared about stability.
That even attempting to fix got deferred to jre18.
From where I, and Im sure most of "the ecosystem" sits "the jvm eventually explodes if you indefinitely add things to and clear an arraylist" is more than reason enough to not update to any jvm with that "feature", 10% hardware savings wouldnt cover a fraction of the support costs there even for those spending significant amounts on hardware.
OTOH, it is quite nice that new adopters will by design never be able to achieve the same stability those of us who have been around the block a few times have.
> Its one example of issues that never should have made it into a release in the first place of any software that cared about stability.
You realise it's been there for many years before being discovered by one of the millions of Java developers out there, yeah? It goes at least as far back as JDK 8.
> From where I, and Im sure most of "the ecosystem" sits "the jvm eventually explodes if you indefinitely add things to and clear an arraylist" is more than reason enough to not update to any jvm with that "feature",
Once again, that bug -- for that particular class of processors -- is in 8 as well, and the crash occurs less often in 17 than it does in 8.
> OTOH, it is quite nice that new adopters will by design never be able to achieve the same stability those of us who have been around the block a few times have.
Those of us who have been around the block a few times have learned to trust data; if there's any trend in the JDK's stability, it's upward. Our process is so much more careful and the testing more exhaustive than it's been in the 8 time-frame.
>You realise it's been there for many years before being discovered by one of the millions of Java developers out there, yeah? It goes at least as far back as JDK 8.
Obviously, since it was me that just spent the last few days explaining stability and migration options went downhill so fast after 8 we got stuck there for production systems.
Do you?
>Those of us who have been around the block a few times have learned to trust data; if there's any trend in the JDK's stability, it's upward. Our process is so much more careful and the testing more exhaustive than it's been in the 8 time-frame.
But adding and removing objects to/from an arraylist was somehow missed from that exhaustive testing?
Or really just not considered an important feature for java to worry about?
Better to spend the dev time deleting security manager, because no one in the ecosystem wants or needs to manage application security from java code?
All that really just sounds like intentional sabotage to me.
This isn't after 8. The bug is there in 8. And your statement that things went "downhill" after 8 is just factually incorrect, which you can confirm based on publicly available data.
> But adding and removing objects to/from an arraylist was somehow missed from that exhaustive testing?
Given that the bug has been in the JDK for at least eight years, and it wasn't detected in production in all those years until now, why is it surprising that it wasn't detected in testing? It occurs only on specific architectures and specific conditions.
> Better to spend the dev time deleting security manager, because no one in the ecosystem wants or needs to manage application security from java code?
You're implying that SecurityManager is used for security, while it hasn't been a security feature in many years (including in JDK 8). It was a security feature for applets, but virtually all features added in JDK 8 and beyond ignore SM, and Java's security features have not focused on SecurityManager, it is not part of the platform's core security, and Java's secure coding guidelines do not recommend using it. We're removing SecurityManager on the advice of security experts, in an effort to improve security. SM does not only not improve security, but might well harm it.
We focus on stability today much more than we did in the 8 timeframe. We have more tests these days that we run more often (thank's to a better CI system), and we merge new features after much more scrutiny and testing than we did in the 8 timeframe. I don't know if you remember, but 8 was largely unusable until the first update. This no longer happens today. New versions are stable on day 1.
I'm sorry you've had a bad experience, and in an ecosystem so large running on so many kinds of machines, it might well happen to some, and, understandably, it paints your views. But looking at the ecosystem overall, there is simply no downward trend in stability, and while we haven't yet crunched all the data, we can tentatively say there has been an upward trend.
I do remember those times tho. When bugs like the jvm exploding doing basic things like adding and removing items from an arraylist for a prolonged period of time would be fixed in the next point release before anyone really realised - rather than left to people who are too busy fixing their own bugs to notice and replicate, resulting in such bugs hanging round for 2 lts releases and a decade later.
>We focus on stability today much more than we did in the 8 timeframe.
Couple of thoughts on this.
Are those tests really capturing the "jvm explodes after 100 hours" issues, like in that bug report. Or are they just "no new segfaults in this short lived jvm run in a VM that just completely changed the gc again and rewrote a big chunk of the thread handling code", I dont have faith they do simply from burning so much dev time previously to find they werent.
But also; it is really nice to see jdk development process stabilise after the terrifying licence changes we got on 8 - Im sailing right now, back in the office soon, however I dont see any adoptium builds for 17, any idea when I can actually check all this myself?
Since you're talking to a member of the team that maintained Java back then, I can tell you that our quality process back then looks like a joke compared to what we have now. Of course, you might have been bit by a problem, but our stability has 100% not gone down (backed by irrefutable data), and most likely has gone up.
> Couple of thoughts on this. Are those tests really capturing the "jvm explodes after 100 hours" issues, like in that bug report.
Once again, whatever we did 8 years ago, we're much more thorough today. We are not bug free, but we don't have more bugs than before, and we probably have fewer.
> But also; it is really nice to see jdk development process stabilise after the terrifying licence changes we got on 8
By "terrifying license change" you mean the 100% open-sourcing of the JDK, and making it 100% open and free for the first time in Java's history that happened in JDK 11? Some people were confused when we made Java entirely free and unencumbered, and made OracleJDK the name of our support subscription, so we've changed it a bit now again. But as of JDK 11 -- and unlike any Java version that came before it -- the JDK is completely open.
> however I dont see any adoptium builds for 17, any idea when I can actually check all this myself?
Adoptium is a project run by an IBM team, and I have no knowledge of their process. Unlike Oracle, Red Hat, SAP, Azul, Bellsoft, and Amazon, Adoptium is not involved in OpenJDK and is not a member of the vulnerability group, so their builds usually come after everyone else's because they're less familiar with the OpenJDK project and its process (they're more familiar with OpenJ9). But I'm sure they'll be able to make a build soon enough.
I didnt (particularily) place any blame. If it wasnt your testing that was catching them early it must have been someone elses. Presumably they left the ecosystem.
>the JDK is completely open.
But a shadow of its former self.
>but we don't have more bugs than before
Im really talking about issues related to very long running jvms.
The kind of things that would have killed applications like apache tomcat dead.
In fact it looks like they use their own jvm build now, I'll give that a go at the same time..... however it looks they they are still really on 8 as well.
Almost everything here is wrong. The prices and licensing terms are very wrong, but, most importantly, what Oracle did was, instead of provide one part-free, part-paid, JDK, we started providing two indentical ones with different licenses: one completely free, and one for support subscribers.
> But a shadow of its former self.
Actually, it has many more features today than it did back in 8.
Not sure if you'll catch this message any time soon, but:
1. major source of incompatibility was the removal of the ability to cast ClassLoader to a URLClassLoader, fixes for that were relatively extensive but also simple enough to get running in a few days.
2. Not seen any crash reports in the first 24 hours which is a good sign, any that do come up I will forward as bug reports.
3. Perf wise, about equal, memory usage is much better.
4. Thanks for the impetus to give migrating another go.
So far so good just default parameters plus an 8gb heap.
>unspecified behaviour
Also the accepted answer on 100+ different websites for how to choose single jars from a folder at runtime that still compiles but now excepts with no easy replacement or even explanation of how to replace it.
If i get time i might write up how i fixed it.
> Also the accepted answer on 100+ different websites for how to choose single jars from a folder at runtime
Which goes to show that not all information sources are equally good. For a couple of decades, we've said over and over -- and still do -- that depending on unspecified behaviour is technical debt that will eventually break your codebase.
> with no easy replacement or even explanation of how to replace it
That's how online givers of bad advice roll -- they advise you do something they know is wrong, and when things go south they don't help you; those who followed Sun/Oracle's advice ran into no such issues. There are documented and supported ways to get the classpath.
(I won't lie, I used that easy trick, too, once or twice, but I did it knowing full well that it might well stop working some day, and treated it as technical debt.)
> We had actually _just_ started a javaFX project only a few weeks before finding out it was removed. That project was binned and we went over to android apps instead.
You were going to start a _new_ project on an old runtime? There’s no logic here.
It was a project started just before 11 was announced along with javafx's removal.
Being removed meant any install on clients machines would be problematic (possibly why it was removed)
So the project was reassessed, and everything that was going to use javafx was replaced with webkit/html5/css/js which was expected to be and turned out to be much easier to deploy and far far more portable.
this is super interesting. Honestly, I do think that your testcase is worth replicating.
I dont think anyone is advocating you tradeoff stability for shiny features, but i think everyone is existing in a state of disbelief that Java 17 would break on your usecase.
But if what you're saying is true... it super duper worth it for everyone to submit that test suite. Java 17 is also LTS ...so that effort would be worth it in the long term.
I really think they are "trading off stability for shiny features"
Oracle wanted money from google for using java to create google search and creating Android.
Didnt get any, and now they are trying to attract devs who are starting similar ground breaking ideas on go and rust with a similar disregard for robust failure states and long term code viability which is always what separated java from its competitors.
Why else depreciate all the features that made it perfect for huge teams building systems that never broke and adding "things rust, go and v8 did"?
as for the test suite, not touched java 17, looking at the "whats new" the main thing I can say for sure is "new" is all the security manager stuff that wraps code made by 3rd parties is going to be marked with depreciated, but no clear upgrade path.
look - the tradeoff here is large vs large.
I detect a certain disdain for Android - however there is probably a larger dev pool right now who want that (versus you).
I dont disrespect your usecase, but any company would have to service its largest market first. And if the largest markets are all Android, Spring Boot, Kafka, Spark, etc... then that's where they will go.
I have been in your situation, but ultimately this is a Python 2 vs Python 3 situation. If you want to stay on Python 2..then you better be able to maintain it yourself.
Its just a larger pool of users on the other side. And this is the common developer on the street wanting to use Kotlin, Clojure, etc. This is the market, so here we are.
java 6 (previously widely deployed jvm) was 2006
java 8 (current widely deployed jvm) was 2014
now, 7 years later, we are on java 17 and the most significant thing to change is to break most everything that worked in 2014, and promotional material dare not mention java 8...
In fact "widely deployed" doesnt cut it for java 6, pretty much every pc, windows linux and mac had a solid java 6 deployment.
> fixing what isnt broken isnt high on the list of things to do.
It's hardly reasonable to try to pin the blame of not wanting to maintain software as a stability issue with a newer LTS release of the JDK. It's perfectly fine if you make the call to stick with JDK8 forever, but that's a personal call.
Much of the improvement came from a re-encoding of String (no longer internally encoded as UTF-16), and more sophisticated GC algorithms.
> If the jvm cant run a day without creating a hcrash report and you need 10 times as many cpus to complete a job in the same time, how is that a step forward?
If you see crashes, submit a bug report, but we've not been seeing any increase in crash reports. It's possible that you're using a library that hacks into JDK internals and is a cause of such problems. Try using JDK 16 or 17, where strong encapsulation is turned on (at least by default).