How much faster is Java 17?
optaplanner.org
optaplanner.org
Wasn't the whole "write once run anywhere" promise about backwards compatibility too?
The idea that the only thing that changed was access to internals isn't really the case, but a lot of these changes were "allowed" because Java cares about compatibility with its own spec rather than specific popular apps.
I thought they just split up the JDK into modules, making some libraries optional for a smaller footprint if you decided to ship your program with the JDK included. I am quite sure swing was also split of and all my toy programs still run despite that.
> JavaEE stuff was removed from the JDK and then re-namespaced,
JavaEE was never part of the standard JDK. Never used it, but you can probably still find the old java package somewhere.
> they moved some stuff out of Unsafe
out of sun.misc.Unsafe, an internal API of the Sun JDK that wasn't in the java namespace, wasn't documented and had nearly every IDE scream at you.
Swing is still distributed with the JDK, but JavaFX isn't. If you use JavaFX, you need to either add Maven dependencies on the JavaFX modules or compile with a JDK distribution which still includes JavaFX (e.g. jdk-fx from Azul: https://www.azul.com/downloads/?package=jdk-fx).
It is ironic that what was originally the most hyped feature of Java has now been removed. But nobody is going to miss it.
They didn't mention the applet part in the job description. That was my shortest tenure ever, including Summer jobs and internships...
> The answer to this question is almost certainly "no".
For me, it's a yes. My employer uses some ancient monitoring application called SiteScope. They recently "upgraded" from an ancient version to a newer one (I think the latest), and nearly the whole frontend appears to be implemented as a Java Applet. Since no browser on the Mac supports Applets anymore, their workaround was to download some Java App that ran the UI.
The older version we had used HTML.
I wonder how effective ancient monitoring software is.
The workaround is actually part of the software itself (there are instructions right below the login box).
My understanding is they're only upgrading because the old version didn't support modern versions of TLS, and there's a big push to get off of those. Finding new monitoring software would be probably be more work. At a minimum, the new version probably supports all the features we're using, and at best all our configuration can be automatically migrated. I don't know the details: I'm not part of the project, I just have an some apps with some monitors setup for them.
> I wonder how effective ancient monitoring software is.
It gets the job done.
If you ever peek at the software some industries are running, you may find yourself extremely surprised. A lot of it is incredibly specific, and truly terrible.
There have been a few minor breaking changes from JDK 8 to JDK 17, but the worst ones have had command-line options to disable them.
Maybe you're referring to JEE and/or specific "enterprise" software which does tend to move much more slowly.
Code still worked but services would easily get overloaded, there would be one piece of code which ran crazy slow, or new memory issues would come up.
It absolutely is not just safe to jump versions in production, usually it’s been weeks of testing finding and fixing perf bugs.
It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients.
I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem.
I’m not surprised that people seem to be leaving the ecosystem.
> I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem.
Could you clarify what you ran into? Why docker? I'll have to do this soon.
So it's not "turn-key" to upgrade to jdk 9 or above, like say, 6 -> 7 -> 8 was.
Sounds simple... "just add it to your maven deps!" - but in practice it's more complicated than that and requires careful planning and testing. Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime.
Java 9 created quite a mess. Once you finish that upgrade though, moving into Java 11 or anything newer is basically turn-key like it was before. But, this had the effect of many companies staying with Java 8 until forced to upgrade.
Not sure I follow why you had to turn to docker
> Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime.
The JVM is deterministic - I don't follow this statement?
I didn't, and OP could have stuck with Java8 since it's LTS. So I'm not sure either where Docker comes into play. It seems the parent was deploying fat jars, and now due to the complications of all the various deps, they opted to use Docker images as a new "fat jar". Perhaps it simplified their build process, but that's just a guess.
> The JVM is deterministic - I don't follow this statement?
Custom classloading simply requires a string path and FQN of the class to attempt to load it from disk. Compile time checking doesn't validate the actual existence of the class, which is the point of runtime custom class loaders.
A lot of plugin loaders are done this way, etc. So... your program might be humming along just fine until it classloads in a plugin (or whatever) that depends on Jaxb for example, then everything explodes since Jaxb is now a dep instead of built into the jdk.
Anyways, I had read your comment as: ~"Classloader loads class X fine one moment and then suddenly can't" which is why I mentioned deterministic.
Well, no it hasn't. Things like Jaxb, for example, have always existed in the JDK since they were introduced (java 1.2 in Jaxb's case). XML processing code compiled with jdk5 (circa 2004) still worked fine on java8, for example, with zero code or dep changes. Suddenly that assumption is broken with java9.
> Anyways, I had read your comment as...
It was just an admittedly contrived scenario where the upgrade path to jdk9+ wasn't as straight forward as just adding deps to maven and calling it a day, since you may not be aware of all code interactions, depending on the system you're upgrading.
Your program might even have a dep on some jar that was compiled under jdk4 and the author and source are nowhere to be found (or went out of business a decade ago)... and suddenly it breaks under java9. Things like that are largely what prevented mass adoption of jdk9 immediately.
Simple: by the end I was dealing with self-signed bodies and validation, version hell, framework hell, and namespace super-hell.
Object: um, not really. It was request/response. Nothing really "OOP" about it at all.
Access: didn't really help much with access, that was all HTTP
Protocol: There were so many protocols and frameworks attached to those protocols and versions of the protocols that ... in the end of the day, it had no protocol.
[1] Oh crap I’d forgotten about SOAP faults until I wrote that word. Please help me I’m having traumatic flashbacks.
There's certainly no requirement to start using Docker images!
It's one of those things I would personally argue is a naughty hack that should be avoided if at all possible, but it's also something that's historically been ubiquitous within the Java ecosystem. It's frequently how convention-over-configuration dependency injection (as found in Spring Boot or Jersey) tends to be done, for example.
The reply I got on Stackoverflow from the person I think is the maintainer is "don't use fat jars", which is probably the correct solution, although most people use fat jars.
Lately, I've been reading that layered docker images should be a faster way to build and deploy java apps that have many tens of MB of dependencies that never change. It only works if you don't use fat jars.
http://harmful.cat-v.org/software/
They should be using rocks instead of a computer with this mindset.
Why would it be ad hominem (which is not even that)? Also, the link I posted is even about the same topic, not unrelated - so a logical flow in that one (and it has plenty) will easily apply just as well to an elaboration of one of the listed contenders on this page.
Just getting code updates on our old java websites makes me realize why all the new stuff is arguably slower php and python..
As long as you're running the same code on both ends it sort of works. It's still over engineered to the moon and back, and a major pita to deal with, but at least the damn thing works.
Anything beyond that fails in spectacular ways.
It will not be missed.
Delving under the XML hood can be painful.
It's very easy to overengineer. Both the SOAP WS-* extensions, and the underlying XML.
The tooling and ecosystem suck. I found it a lot more difficult to use clients like soapUI as opposed to just banging on a REST API with curl. The libraries are mostly java, with at least one c/c++ implementation. I had a lot of trouble getting different libraries to work together. And that's literally the entire point of SOAP. It's supposed to be the enterprise grade interoperability (of course, a huge oxymoron) compared to REST.
I spent a few years working on SOAP for a telecom. Not pleasant.
Please mention a few of these problems, I'm curious to hear.
The problem I see with REST/JSON-APIs is that they lack features that have to be tacked on after, creating an endless bikeshedding nightmare and instead of having one well-thought out solution, you get three or four solutions sloppily hacked together. Schemas are a prime example, actually: SOAP appears to come with them out of the box, while REST/JSON-APIs either lack them (just about as bad as not having any type system in your language, i.e. really bad) or tack them on after the fact with something like OpenAPI, which is honestly not great as far as schema languages go.
Again, I say this as someone who has professionally used SOAP only once, and very briefly at that. Not advocating that we should re-adopt SOAP - I think that ship has sailed since long ago - but I really want to understand its opponents opposition to the positive qualities it appears to have.
> Schemas are a prime example, actually: SOAP appears to come with them out of the box, while REST/JSON-APIs either lack them (just about as bad as not having any type system in your language)
The problem with SOAP is that it seemed to be designed by multiple committees with different agendas. From my imperfect memory, it's not just different versions of SOAP you have to contend with, but also different variants of schema flavors. Consequently, different languages and even libraries would have implementations that might support x but not y schema feature. It was an annoying compatibility nightmare, where you needed an additional complicated tool to verify it all.
Yes, JSON/REST have their own issues, but it's nothing that good documentation can't solve, and it's supported across most if not all major programming languages. Simplicity is often very underrated.
I’m no fan of that, but unfortunately we are forced to use some such SOAP services.
But why? What changed in the spec that forced a rewrite?
Also most of the breaking changes from Java 8-11 are/were not spec changes. The spec leaves out many aspects of the Java platform that real apps rely on.
This idea that only apps that used JVM internals broke is totally wrong. I think the guys who work on Java think this because they don't actually use or work on any Java apps themselves beyond the ones that are a part of the JDK itself.
People don't execute specs, they execute implementations. In the end whether something is or is not fully compliant with the spec doesn't change the costs involved in fixing it.
The main backward incompatible changes between 8 and 9 were the changing of the version string to remove the "1." prefix, and the removal of a handful of methods hardly anyone had used. In other words, the chances of spec-compliant code that ran on 8 failing on 9 were slim. What happened was that in the long 8 timeframe, many libraries -- for various reasons, some reasonable -- have circumvented the Java spec and hacked into JDK internals, making themselves tightly coupled to 8. When internal classes changed in 9, those non-portable libraries broke, and so did their clients. Now that strong encapsulation is finally turned on (as of JDK 16), this shouldn't happen again.
There were some significant breaking changes to the spec in 11, but those comprised separating modules from the JDK into external dependencies, and didn't require any code change.
My company migrated from 8 to 11 but we had a lot of headaches around those libraries that were pulled out of the jdk.
To be fair, those should not have been coupled to the jdk in the first place, but it did break backwards compatibility which was a cardinal sin for java.
Although, if it gives you a stack trace even faster than before, I guess it could be considered a performance improvement...
I'm not sure if that's a real problem. All it takes is to add few dependencies to pom.xml.
But it was worth it. Got us access to the java flight recorder which is an awesome debugging tool.
when we moved from java 7/8 to java 11 two years ago, we didn't had any issue with our third-party libraries, but we had a few pieces of code, mostly related to encryption libraries, that failed to compile with the newest JDK
edit: although this appears to have recently changed! https://blogs.oracle.com/java/post/free-java-license
It was really a terrible idea from a security perspective - and unfortunately there are organizations that won't consider software without a support contract.
1) Certain libraries that were part of the JDK being moved out of the JDK, which usually required adding them as a module or dependency in $BUILD_TOOL_INSTRUCTIONS_FILE
2) Internal JVM APIs that weren't public being used via reflection by clever libraries, and then when they change, those libraries break
3) Bytecode emitting libraries - various frameworks love these, but bytecode that worked for Java 8 can fail on Java 9. Hence Spring 4 only supports JDKs 6 - 8. So to move to JDK 9+, you had to upgrade Spring to 5.x, and things that were tied to your version of Spring... and this process can very often suck.
4) New versions of library X only being available in class formats that Java 8 can't run. I encountered this with Jetty - version 10+ only support Java 11+, so if you're stuck on Java 8, you're limited to bug fix releases on the last version that supported Java 8.
Since Java 9, the JVM has been warning if you use internal APIs. As of Java 17, they have started enforcing strong encapsulation of those APIs ("private means private yo"), to give the JDK freedom to evolve without worrying about every library that got clever with the internals of the JVM. But given the very long lead time and ample messaging on this, I don't expect Java 17 breaking too many things.
At my last job, we had a rather large monolithic build that was tied to Java 8 because some modules would die a horrible death when compiled with or for a higher version Java. So I introduced Maven and Gradle toolchains[1] so that individual modules could compile using their preferred Java version, which freed up new modules/apps to use Java >8 as they saw fit. All the legacy apps that broke on Java 9+ could stay on 8, but the rest of the project was freed from their legacy crap.
[1]: https://docs.gradle.org/current/userguide/toolchains.html
Nothing can ever be finished, there must be "upgrades"!
That left me with the impression that stability and performance had been abandoned over throwing everything including the kitchen sink at it to try and attract people who like rust and go.
Could be wrong, but the hand waving away the implication that 17 is slower than 15 at the end and not even trying to compare with 8 which is rock solid and crazy performant leaves me thinking nothing actually changed.
They concluded:
"JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pauses."
its target is throughput rather than response so yep "pauses", but the entire job takes 4 hours instead of 40. In production those pauses vanish with load balancing.
checking for jdk8 vs jdk17 turns up
https://www.google.com/amp/s/www.infoworld.com/article/36068...
"New Relic found that nearly 100 percent of users are running either JDK 11 or JDK 8, the two most recent LTS releases."
so 17 being 8% faster than 11 apart from when its 10% slower, "maybe" slower or faster than 15 but they chose not to do a like for like comparison.... but 11 being catastrophically lower throughput than 8....
I may get some time soon to do some benching, I dont want to be back on 8, but the benching I did for at least 10 and 11 just made them a no go, completely crashing the jvm was an even bigger issue than the time.
Definitely not sure it was that op exactly, reasonably sure it was something related to it (maybe it no longer working with a gc it used to).
TLDR:I found out "the hard way" -XX means "jvm specific, can change meaning at any time and is jvm vendor specific".
oracle java 8 had a sweet spot that made perf awesome, nothing since has come close.
thought that may actually be part of the issue - not keeping things that benefited from that persistence around long enough. Traded throughput away for smaller lookup tables.
As for "medieval technology" in what way? 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?
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).
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?
Aren't they every 2-3 years?
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.
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.
java 17 has a lot to live up to.
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.
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.
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.
> 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.
here is the documentation I found describing what i would see in anything on post jdk8 that would compile:
https://docs.oracle.com/en/java/javase/11/troubleshoot/fatal...
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.
>CORBA works fine
Use almost everything removed in https://docs.oracle.com/en/java/javase/11/migrate/index.html
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.
Start by submitting the hs_err file.
> almost everything removed
It was removed from the JDK and made available as a separate module (contributed to Eclipse): https://github.com/eclipse-ee4j/orb
> 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.
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.
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+.
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.
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?
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+.
Having just read the release notes: https://jdk.java.net/17/release-notes
links
https://bugs.openjdk.java.net/browse/JDK-8263710
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.
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.
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.
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.
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.
Reasonably certain its not before 8 :)
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?
Well, the bug dates at least as far back as 8.
> I do remember those times tho.
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.
They replace adoptOpenJDK https://adoptopenjdk.net/ ...
>By "terrifying license change" you mean the 100% open-sourcing of the JDK, and making it 100% open and free
No, I mean
https://www.policypak.com/resources/pp-blog/oracle-java-lice...
>Once again, whatever we did 8 years ago
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.
Yep, it's the same IBM team, who aren't involved in OpenJDK (and weren't when they were called AdoptOpenJDK). They mostly know OpenJ9.
> https://www.policypak.com/resources/pp-blog/oracle-java-lice...
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.
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.
> major source of incompatibility was the removal of the ability to cast ClassLoader to a URLClassLoader
Right. That was an unspecified behaviour, though, that just happened to be true for a long time so people depended on it.
>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.
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.)
You were going to start a _new_ project on an old runtime? There’s no logic here.
https://www.infoworld.com/article/3261066/javafx-will-be-rem...
11 is still the most recent LTS version, 17 doesnt even have a openjdk release yet
never migrated to 11 because nothing we have running perfect on 8 ever passed its unit tests on 11.
Even the 17 release notes basically seem to imply 17 is not ready for production.
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.
At a prior employer, we ran a heavy-duty compute engine and a bunch of other services on Java 13 (don’t ask) without any issues. Stupid JDK tricks in dependencies were the hard part of migrating 8 to 13.
You should look at your codebase, you might be doing some strange things that changed in newer JDKs (e. g. String split no longer uses the sour String, but I don't remember when they changed that). Some options were deprecated because they are also always on (not all probably).
what in 17 do you think is worth risking downtime?
I mean, if you don't want or feel the need to upgrade then don't. There are plenty of reasons to do so IMO.
a bug that takes 100 hours to manifest takes multiples of that to fix.
compute and ram is crazy cheap these days, developers are not, and finding good ones is harder than ever.
since you threw them out, which "majority of users" are you thinking of?
If you are wondering why no one wants to pay for it, that is why.
Maybe you should quit being lazy, learn the new JDK APIs and features, and convert that POS legacy codebase into something that's not dependent upon a platform released 7 years ago. But then again, maybe you're not a competent enough developer to do so, so you blame the JDK developers instead.
But now that I do, i still have no interest in anything you think you know, you sound like the kind of dev I could replace with a 14 year old on $2 an hour.
Luckily I didnt, say, not do any java since jdk8 was released and instead waste my time on worthless, soul destroying bash scripts.
If I did that, rather than linking you a 30 second youtube vid of my check ride last month
I'd be the worthless POS instead of you.
I dont feel sorry for you, you mostly make your own luck, and a quick check of your comment history suggests we both have the life we deserve.
Didn't you had to install updates and patches during the past three years? Or were those sacrificed to keep an uptime streak that matters nothing?
JDK11 was released way back in 2018. Any claim that it's unstable these days is not credible.
e.g. a non insignificant portion relies on corba/rmi. it works, and works fine.
switching, e.g. https://stackoverflow.com/questions/51710274/is-there-a-repl...
might break in unexpected ways, bringing down everything that needs it.
I see 17 is potentially ripping out security manager, why? wth?
So suddenly jars that expect to throw an exception if 3pd code wants to do something they arent allowed to will now just run fine?
Really really very sad face.
Because Security Manager — which enforces runtime access capabilities, like an OS kernel does — exists for the sake of Java applets, and Java applets have been dead for a long time. The Security Manager enables secure execution of "mobile" (i.e. untrusted, not-auditable-at-time-of-release) code — cases where the "host" and "guest" codebases are compiled separately with the "host" having no ability to introspect the "guest" during the "host's" compilation, because the "guest" doesn't exist yet.
Security Manager does not exist for the sake of fighting against your own project's dependencies. There are much simpler and more runtime-efficient solutions (like linters / static-analysis tools) for the case where the "host" can see the "guest's" code at compile time.
Security Manager doesn't exist for the sake of "plugins" (e.g. WARs, Java Agents, etc), either. Even if you don't have a plugin's source code available in your project worktree at build time, you can still validate the plugin's behavior at release time by statically analyzing its bytecode before building it into your release fatJar. Which still allows you to make much stronger guarantees than Security Manager can.
why do it?
No modern ops staff would trust the JVM to not be exploitable if you're exposing it as an attack surface to arbitrary user-supplied (or "third party dev who is incentivized to make a network call you don't want them to make") bytecode. Creating that kind of boundary is what technologies like gVisor and Istio are for; it's not the job of a programming-language runtime. (See also: the decline and fall of Google App Engine's "secure runtime" standard environment, in favor of the gVisor-based flexible environment.)
(Well, okay, Node and Lua are both runtimes that have trustworthy VM-level isolation that can be used to achieve this — see Cloudflare Workers for the Node case, or Redis scripting for the Lua case. But this is because Node and Lua both have "shared-nothing" runtime execution semantics with no concept of static-bound identifiers [i.e. constants] — meaning that all the fundamental "stuff" available in a Node or Lua execution context is put there dynamically, and so a sandbox can be constructed "from scratch" with arbitrary stuff [mocks/stubs/proxies] inserted in place of the fundamental module handles, to create a whitelisted environment. The JVM is not built like this; the JVM's Security Manager merely blacklists certain known-dangerous operations, and so does nothing to prevent exploitation of zero-day vulnerabilities.)
Correction: Cloudflare Workers does not use Node, explicitly because Node does not provide secure isolation. Workers uses a custom runtime built directly on V8, which does provide secure isolation in the way you describe.
As for Lua, it might work in theory, but I don't think it has had anywhere near the scrutiny V8 has had. I wouldn't bet on it when security really matters.
Re: Lua, I don't know about "scrutiny" in the code-audit sense, but I believe that there are a few battle-tested deployments of Lua in entirely-untrusted sandboxing use-cases. Some games (e.g. Minecraft's Computercraft mod) allow players to deploy arbitrary Lua scripts which are then executed on other arbitrary players' computers; and yet nobody's managed to nuke anyone else's hard drive through these scripting mechanisms yet, despite griefers having high motivation to try.
For the same reason that blockchain software continuing to exist makes me have a lot more faith in the collision-resistance of SHA256 (despite a lack of cryptanalytic proof of such), I'd trust a tightly-constrained Lua sandbox. (In both cases, of course, there might be a state-military-level adversary with a vulnerability in hand, who doesn't want to show their hand for something as trifling as money. But such an attacker is highly unlikely to deploy their exploit against my service in particular, even if they have it.)
Given a fixed pool of developer resources, eliminating unused per-change overheads like this, serves as a multiplier for the project's ability to do everything else. The time freed from core devs by not writing Security Manager instrumentation for everything, could be instead allocated to e.g. getting Project Loom stable and upstreamed.
And that's assuming that everyone even does the Security Manager instrumentation of each new thing perfectly. The devs doing that instrumentation don't use Security Manager any more than a random Java dev does, so they likely don't know its ins and outs. Every new patch is thus a new opportunity for someone to bungle the Security Manager instrumentation, and thus for exploitable JVM surface area to be created. The more time that goes by, the more likely such exploitable surface area is to have already been introduced and gone entirely unnoticed by a population of developers that just doesn't use the feature. And so, the more time/patches that go by, the more that the Security Manager shifts from being a harmless thing to leave around, to a land-mine waiting to strike any dev who does try to use it.
(The "blacklist where at any point a new feature could be added and its security implications missed" problem is the same reason it's hard to trust SELinux—but at least SELinux is used by default for securing system components in some Linux distros, so at least SELinux policies gets pulled in on a regular basis as part of other companies' security audits of their stacks. Security Manager isn't used by default anywhere!)
It always was? None of that solves the problem of blacklisting certain actions or logging for audit based on the content and/or origin of the data being processed.
Ignoring such things does explain why and how modern enterprise-y solutions are leaking like sieves tho I guess, e.g. solarwinds would likely never have happened if they implemented proper application component level permissions.
Because it is not used by any modern (post Java 6 probably) feature in Java?
So why keep such thing? If libraries want to use such features they can create their own.
We will definitely move to 17 already next year.
We did a comparison of Java 8 and Java 11. And that was a good jump too: https://www.optaplanner.org/blog/2019/01/17/HowMuchFasterIsJ...
Now, you can't just sum op those percentages (different code base), but that sum would be a starting estimate I think.
TLDR: using the same GC (*), it's 4% to 16% faster (depending on the GC).
But be warned that if you don't set a GC, Java 8 uses Parallel GC (high throughput, so faster) by default and Java 11 uses G1 GC (low latency, so less hickups) by default.
[1] https://docs.spring.io/spring-native/docs/current/reference/...
[1] https://docs.spring.io/spring-native/docs/current/reference/...
- Java 8/11 uses ~ 550MiB
- Java 17 uses ~ 260MiB
JDK 8 -> JDK 11 gains were huge thanks to String optimisations (e.g. GC could dedup strings and store one char as byte in many cases).
Good to find that the assumption was correct, lol.
I recently listened to an interview with someone working on Intel's C++, and he indicated that, contrary to popular assumption, most of the speed boost you can get with it isn't from better instruction-level micro-optimization, it's from analyzing information flows and maximizing locality of reference.
Perhaps this is an inevitable result of that ever growing processor-memory performance gap. Nowadays, the cost of having to take a walk of shame out to the RAM chips is so great compared to everything else that I would assume that minimizing the number of times you have to do that is by far the lowest-hanging fruit.
The kotlin workaround hacks are clever but also nasty and having real VM support for this would be great. But it also is starting to seem like the type of issue that just won't ever be fixed, despite how hugely important it is for performance.
It looks like there were some experiments and prototyping out of Valhalla from 2014-2018 (including a publicly available build: https://jaxenter.com/java-value-type-163446.html ), but there doesn't seem to be any updates since then
Oracle (Brian Goetz in particular) regularly gives talks and interviews and publishes updates.
There was even a link on this site a couple weeks ago: https://news.ycombinator.com/item?id=28364500
[1] https://github.com/openjdk/valhalla/ [2] https://mail.openjdk.java.net/pipermail/valhalla-dev/
If you've never heard of constraints programming -- it's really interesting (personal opinion).
It lets you programmatically state "rules" and "goals" of some system, and solvers will automatically attempt to find the best solution.
Optaplanner is one of the most advanced of such engines that I'm aware of:
Under the hood, OptaPlanner combines sophisticated Artificial Intelligence optimization algorithms (such as Tabu Search, Simulated Annealing, Late Acceptance and other metaheuristics) with very efficient score calculation and other state-of-the-art constraint solving techniques.
https://www.optaplanner.org/blog/2020/04/07/ConstraintStream...
I got interested in this area some years ago, and reached out to Geoffrey personally. He took the time to reply to me and answer a few questions. Great person, he's brilliant and super passionate about the domain.
If you have any sort of practical usecase for this (scheduling, vehicle routing, cost optimization, etc) and this sounds at all interesting, highly recommend giving it a shot!
As an example of what you can do in a few lines with this, here's one from the docs:
The following code snippet first groups all processes by the computer they run on, sums up all the power required by the processes on that computer using the ConstraintCollectors.sum(… ) collector, and finally penalizes every computer whose processes consume more power than is available.
private Constraint requiredCpuPowerTotal(ConstraintFactory constraintFactory) {
return constraintFactory.from(CloudProcess.class)
.groupBy(CloudProcess::getComputer, sum(CloudProcess::getRequiredCpuPower))
.filter((computer, requiredCpuPower) -> requiredCpuPower > computer.getCpuPower())
.penalize("requiredCpuPowerTotal",
HardSoftScore.ONE_HARD,
(computer, requiredCpuPower) -> requiredCpuPower - computer.getCpuPower());
}
As a bonus, it's natively integrated into Quarkus and the Quarkus ecosystem. Quarkus is the best thing since sliced bread if you're on the JVM and are writing API's.
https://docs.optaplanner.org/latest/optaplanner-docs/html_si...
* Dozens of solvers with hundreds of search methodologies
* Intermediate Language specifications (FlatZinc) to allow solvers written in one language to interact with completely different languages via a common intermediate language.
* Entire catalogs of useful constraints https://sofdem.github.io/gccat/
* Solver Competitions https://www.minizinc.org/challenge.html
* Peer Reviewed journals https://www.springer.com/journal/10601
Posing SMT-problems though … that’s an art. There’s not enough resources for “problems at scale” for me to just dip my tie into…
Paper: https://www.usenix.org/system/files/osdi20-suresh.pdf
Code: https://github.com/vmware/declarative-cluster-management/
This lets you use data from standard, JDBC-supported SQL databases and write constraints as plain SQL-like queries?! This reminds me of an idea I had about embedding a solver API in Postgres using it's extension functionality and being able to make SQL "VIEWS" that represent solver results, like a delivery route or employee roster.
CREATE VIEW todays_employee_schedule AS
SELECT ...
CHECK row_satisfies_constraints(...)
// Create an in-memory database and get a JOOQ connection to it
final DSLContext conn = DSL.using("jdbc:h2:mem:");
// A table representing some machines
conn.execute("create table machines(id integer)");
// A table representing tasks, that need to be assigned to machines by DCM.
// To do so, create a variable column (prefixed by controllable__).
conn.execute("create table tasks(task_id integer, controllable__worker_id integer, " +
"foreign key (controllable__worker_id) references machines(id))");
// Add four machines
conn.execute("insert into machines values(1)");
...
// Add two tasks
conn.execute("insert into tasks values(1, null)");
...
// Time to specify a constraint! Just for fun, let's assign tasks to machines such that the machine IDs sum up to 6.
final String constraint = "create constraint example_constraint as " +
"select * from tasks check sum(controllable__worker_id) = 6";
// Create a DCM model using the database connection and the above constraint
final Model model = Model.build(conn, List.of(constraint));
// Solve and return the tasks table. The controllable__worker_id column will either be [1, 5] or [5, 1]
final List<Integer> column = model.solve("TASKS").map(e -> e.get("CONTROLLABLE__WORKER_ID", Integer.class));Yes it could be applied to general problems as well. In fact, we used it once to plan a program committee meeting. The library (DCM) has no idea what problem setting its being used for, and has no semantic info about the problem other than the schema and constraints we tell it about.
That said, the current focus is on things like incremental computation, debuggability, automatically subsetting the relevant state from the DB, and scalability to really large cluster sizes (O(50K) nodes), which are more useful in the cluster management context than general-purpose constraint programming tasks.
Edit: Also worth mentioning is that your intuition is spot on. The earlier versions of the library went with a CREATE VIEW syntax as you wrote it out. Now that we have a customizable parser, we have since changed it to CREATE CONSTRAINT for clarity.
OptaPlanner is a team and community effort. Credit goes as much to each of them (see team page) as it does to me. And we're standing on the shoulders of giants (other open source projects).
Is there a convenient way to reach out to you or your team with questions? Do you accept outside pull requests?
As for community questions, the best place for public questions is stackoverflow [1]. For private questions and enterprise-grade support, contact my employer (Red Hat) about our paid support subscription, which pays 99% of the optaplanner's development work.
But anybody who wants to use a JDK built by Oracle can choose between the Oracle OpenJDK build [1] with the GPLv2 w/ classpath exception license, and now have the option to use the OracleJDK free of charge in production with a one year overlap between LTS's [2].
[1] https://jdk.java.net/ [2] https://blogs.oracle.com/java/post/free-java-license
OptaPlanner is best of with Parallel GC (high throughput), but most java processes (REST services etc) are much better off with G1GC (low latency) and its siblings (Shanandoah, Z GC).
How about gradle? I really dislike gradle.
How is that “just GC times”?
> "0.37% faster than Java 16 for ParallelGC"
> "2.41% faster than Java 16 for G1GC (default)"
But as you asked, toy benchmark programs!
> When we benchmarked JDK 15, we saw that Java 15 was 11.24% faster than Java 11. Now, the gain of Java 17 over Java 11 is less. Does that mean that Java 17 is slower than Java 15?
> Well, no. Java 17 is faster than Java 15 too. Those previous benchmarks were run on a different codebase (OptaPlanner 7.44 instead of 8.10). Don’t compare apples and oranges.
Author is defending their other article by discrediting their own methods - what those percent values even mean if they differ so much between different versions of the same benchmark? Shouldn't benchmarks be profiled for specific workload types to simulate real life examples? How could you possibly change the workload so much it affects result so significantly and not change the nature of your benchmark?
1) They are not the same benchmark. The Java 15 blog used optaplanner 7.x with optaplanner-examples 7.x, which use scoreDRL. The Java 17 blog used 8.x versions, which use ConstraintStreams. That scoreDRL vs CS is a huge difference, which you see on the numbers (run on the same machine).
2) Remove the Machine Reassignment (B1 and B10) numbers, and it will look consistent: Java 17 is always better. The real question is why is every JDK's (11 too!) performance is predictable on most use cases, but horribly so on the Machine Reassignement case?
3) I need to share the numbers of the 3 raw runs - and probably do more runs - to clearly show and explain what's going on there. It looks to damn fishy.
Oracle JDK builds are also now free:
Java does not belong to Oracle, it belongs to whom ever codes Java. I have still to find a company that understands open-source.
What is not free is support for a specific older version.
So, if that had applied to 11, it would lose updates from Oracle in 1 year from now. Whereas something like Corretto is currently committed to Java 11 updates until 2027 [0].
They seem to also be planning to increase frequency of LTS to every 2 years, so, basically assuming you upgrade to next LTS immediately (unlikely in any moderately complex app with deps) you have 3 years of free updates.
No thanks.
[0] https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-co...