Reasons to upgrade from Java 8
mikemybytes.com
mikemybytes.com
JREs are no longer distributed by Oracle. For client-side stuff, there's a linking tool called "jlink" that creates a minimal JRE for your app (and now you're responsible for keeping it up to date). Oracle wants a license to use their distribution. All that is a lot to catch up on.
IMHO, the best approach is to avoid anything Oracle touches and stick to OpenJDK. For a lot of corporate environments, that's anathema though.
I thought that was just the obvious path; why would companies not like it?
At that point you might as well pitch migrating the tech stack to .net
And I have trouble crediting the idea that moving to openjdk is anywhere near the effort to move to a completely different language+platform, even if there are differences.
My second point was a joke, still I wouldn't be the one to rock the boat. If anything is even slightly off after switching to open JDK you'd need to justify it
Once upon a time maybe, but today:
> A copy of the latest OpenJDK comes bundled with Android Studio 2.2 and higher, and this is the JDK version we recommend you use for your Android projects.
- https://developer.android.com/studio/intro/studio-config#jdk
> If anything is even slightly off after switching to open JDK you'd need to justify it
"We don't have to license it from Oracle" should justify a lot.
For me recent means JDK 14 or later.
OpenJDK and Oracle Java are as different as Red-Hat Fedora and Red-Hat Enterprise Linux.
If you don't want to pay for Red-Hat Enterprise Linux support, just go with Fedora, or any other Linux distribution.
It is exactly the same with Java distributions.
> just go with Fedora
I'm not disagreeing with this at all, but I do want to point out this was CentOS a couple months ago!
Having migrated some respectably sized projects to OpenJDK in my experience it's more work to migrate a codebase to a new Java major version than from Oracle to OpenJDK.
Now, Java like C or C++, enjoys multiple implementations, so even across OpenJDK, J9, Azul, PTC, Aicas,..., there will be differences.
In a comment in another sub-thread you said "Except that since several releases Oracle Java is basically OpenJDK + Support." But that would be more like CentOS and RHEL, not Fedora and RHEL.
1. OpenJDK is the name of the one and only Java implementation by Oracle (other companies contribute, but Oracle does ~90% of the work); all OpenJDK distributions -- from Amazon's through Microsoft's to Azul's Zulu -- are licensed to you by Oracle (read the license); and if you report to Amazon about a big in Corretto (their OpenJDK distribution), most of the time they'll forward it to us at Oracle to fix, because we're the ones actually developing the thing. So if you want to avoid anything that touches Oracle, OpenJDK is what you should avoid as that is the name of Oracle's implementation (look at the logo! https://openjdk.java.net/). But the "licensing mess" is Oracle open sourcing the entire JDK for the first time in Java's history, and using the name Oracle JDK as the name for their support subscription; if you don't want support, download the JDK from Oracle from http://jdk.java.net/, which, unlike all JDKs prior to 11 is actually completely free. The only licensing difference is that whereas the JDK used to be part open and part proprietary, part free and part paid, it is now 100% open and free. Oracle sells you support, or you can buy it from other companies that also offer support.
However, if you're on 8, your licensing situation is more problematic. Like all JDKs past their end-of-public-updates, you now have to pay for support, or use a free OpenJDK 8u build which 1. only contains backported patches that don't cover the entire JDK and 2. predates the full open-sourcing, so isn't identical to the old Oracle JDK. So not only is the license for versions past 11 better than ever in Java's history, the licensing situation for 8 is not that good because 8 is well past its free support period. Licensing alone is a reason to update.
2. There is no JRE anymore because there are no Applets and no Web Start, and so the model of a centralised runtime is not needed and has been replaced by something much better: custom bundled runtimes easily created with jlink. You, as the application's creator now have full control over its Java runtime, and your users don't need to interact with a third party, or even know or care that your application uses Java.
I investigated creating a library for Java recently, and could have made a pretty decent API for Java 9+, but with so many people on Java 8 and below, it might not have been worth it.
I (and I guess many other people, looking at JVM adoption numbers) do prefer a very stable and proven environment. I don't want to discover that "It would work/perform on 15 if only this and this was changed..." and re-test everything two times a year.
So yes, I can afford to run what I know versus debugging all night to save one second of startup time.
[Source] From last year's Snyk report:
- 1 in 4 developers use the Java SE 11 in production
- 2 in 3 developers use Java SE 8 in production
- 50% of developers use OpenJDK distributions in production
There's no breakdown of how much better in terms of how much money you'd save based on the number of servers you're running.
Conversely, there's no estimate of how much a migration from Java 8 to Java 15 or 16 would cost in developer time.
IMO the problem with calculating precise savings is there is no "standard" use-case that could be used as a reference. I took one real-life application as an example in order to be more precise than just "it's somewhat faster", but the benefits will differ based on many different things (platform, app size, frameworks, etc.).
The faster startup is nice, but the biggest advantage is in the memory usage. G1 past Java 8 actually releases memory back to the OS instead of keeping it forever. In addition, I've seen applications use 1/7th of the heap space after upgrading. This translates to being able to significantly lower the memory limits for applications without worrying about OOMing. I haven't moved enough services to see the difference in CPU, but it looks promising there as well.
So if you have downtime now (ha ha), you might as well migrate to 11.
I don't really get what migration issues people experience in practice.
The only concerns I can think of are dev ops related, not code related. Even there I'm struggling to think of big blockers (might have to remove some deprecated JVM flags). The only things I can think of are extremely precise tuning of JVM parameters for one particular use case and then needing to double-check that your performance hasn't degraded based on that tuning.
EDIT: After seeing some responses I should clarify, especially because I wasn't all that clear in my initial question. The article is mainly talking about upgrading the JVM rather than upgrading your compiler. So just take all your class files and dump them into a new JVM rather than regenerating your class files from a new Java compiler. Has this caused substantial problems for people in the past?
Upgrading 8 -> 11 is a lot harder than upgrading 11 -> 17 will be.
These most often means new API, new bugs, new regressions...
* It exposed a kernel panic bug in our Linux kernel when Hadoop applications de-allocated huge amounts of RAM at once (e.g. a Spark program with a 100GB heap exiting suddenly would panic the system)
* It introduced a weird UI behavior change in Swing in one of our desktop apps. In fairness, whoever wrote the app first did some weird unnecessary shit with JComboBoxes, but it was still somewhat odd to me that the behavior changed. The bug was like, when previously if you clicked a box it'd swap it out for a JComboBox that had the previous content of the non-combobox-view-thingy that was in its place. On 8, for some reason it would always be blank and discard the old content. Don't quote me on this description, though. It was a while ago and it was a weird interaction regardless.
So, idk. It's always something. Software, eh?
Such Java users certainly cannot afford to upgrade. However, I do think it's cool to see improvements in Java. Certainly Oracle can be blamed for some of Java's neglect, but I do think enterprise app servers played their part in limiting the potential of Java as a language.
The license change they made in April 2019[1] means that you either need to get off of the Oracle provided java anyway, or start paying them.
And, if you have to test/confirm that an OpenJDK release works, why move from Oracle Java 8 to OpenJDK Java 8? Go ahead and jump forward since you have to regression test anyway. It is higher effort, but you have the hood open already.
It doesn't help much Koltin if those libraries can no longer be accessed with its FFI.
I suspect this is due to a number of reasons. Go doesn't have a separate runtime component so an upgrade is simply a recompile.
I think Go's 1.x compatibility promise has also helped a lot with people feeling confident in upgrading. The Go team tries very hard not to break any existing programs with any of their changes through all 1.x releases.
My take away from this is if you are building a platform, don't underestimate the value of stability across upgrades. If upgrades are painless your users won't mind upgrading. If upgrades are a big ordeal, your user will put off upgrading until there is no other possible option.
1) There is nothing really compelling (despite what the article says, the performance improvements aren't that important for many real-world applications) 2) For this particular upgrade (anything beyond 8) the Java modularization introduces a pain for some libraries. I suspect that 9->10->11->...16 is totally painless, but 8->9 introduces a little bump.
And sadly the security issue is an externality to the owner of the client code. So unless you threaten to cut off their access they don't have much motivation to upgrade.
Sorry to hear that it could be confusing. I will look at its contents once more soon looking for some improvements.
I didnt read the second half because I couldnt make sense of the negative headline with the positive text.
It wasn't though... not sure why you got that impression? (I do think though that the text could use a few edits for easier reading - maybe it just isn't easy to understand when skimming)
Merely making assessments of an article after only reading a fraction of it (or the title!) is bad enough, but spreading those misunderstandings to other people is even worse - not only are you harming their understanding, but you're also misrepresenting the author's points.
In addition, nowhere near "half" of the article is praising Java 8 - the very first paragraph says "This is one of the reasons why Java 8, almost 7 years after its first release, is still widely used.", which is barely "praise", and then the rest (>80%) recommends that you not use it.
In other words the title should be read as "[Java 11/14/etc is so good that] you can't afford to run [i.e., stay on] Java 8"
I agree that the title was a poor choice though.
I promise to be more careful when picking up the title next time. I hope that the article's content somehow compensated that ;)
It seems java was relatively stable from 2006 to 2016, where there where three versions. But instead of slowing down, there have been 8 since then. They`re on v16 now?!
...I doubt I`ll ever code in java again.
Still Java 8 for the most part. Java 11 is actually allowed, but not many people care including me. Existing Scala code is getting thrown away and rewritten back into Java.
JDK is different story tho. I think devops are actively experimenting to put 11 into base image by default, but startup time different is funny argument. 1 second, really? By the time your usual spring boot service comes up and connects to all topics and caches and what not it's good part of a minute anyway.
Is it really _confusing_? The idea that a product might change release cadence probably should not be confusing.