Reasons to upgrade from Java 8(mikemybytes.com)
mikemybytes.com
Reasons to upgrade from Java 8
https://mikemybytes.com/2021/03/16/you-cant-afford-to-run-java-8/
79 comments
IIRC wasn’t there a huge change in how APIs were exposed from 8 to 9 as well?
Yes modules, but all the libraries in the Java eco-system that matter have long supported it, remember we are at Java 16 now.
That’s all well and fine for third party libraries, but less so if you work at some company with some internal framework or whatever using the old system still.
There are also companies still using Red-Hat Enterprise 5 in production with Java 4 (1.4), but I tend to avoid dealing with them as much as possible.
In that case why don’t they move to Amazon Corretto or other enterprise OpenJDK distributions?
> 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?
I thought that was just the obvious path; why would companies not like it?
Open Jdk tends to create random and strange issues.
At that point you might as well pitch migrating the tech stack to .net
At that point you might as well pitch migrating the tech stack to .net
That would be somewhat odd; isn't Oracle building off the openjdk as well?
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.
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.
To be fair I haven't seriously touched java in about 4 years. I do remember Android studio explicitly warning users to avoid Open Jdk
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
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
> I do remember Android studio explicitly warning users to avoid Open Jdk
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.
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.
I'll admit when I'm wrong.
Thanks for the info
Sorry but that is the typical FUD regarding Java and Oracle.
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.
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.
A problem is taking a company's entire Java codebase that's been running on Oracle JRE's, compiled with Oracle JDK's, written to work around Oracle bugs, for a decade, then trying to throw that on OpenJDK JRE's, compiled with OpenJDK JDK's. If it's a huge codebase then performance and runtime errors alone are concerning enough to stay frozen on 8 for as long as possible, without even considering code migration.
> 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!
> 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!
I'm sure you know exactly what you're talking about... but I can't really imagine what major incompatibilities you're seeing while doing these upgrades. Java is amazingly backwards-compatible in my experience. I don't think I've ever had to change anything during an upgrade, in my entire career, except sometimes a couple of minor things to do with Unsafe. I'd love to hear more and some concrete examples if you're able to.
I have no experience in upgrading Java versions or the corresponding code changes required. I have witnessed runtime differences, related to performance and GC behavior, from Oracle 8 to OpenJDK 8 that were unexpected enough to warrant temporarily sticking with Oracle in exactly one case.
That is eons ago, in Java 8 there were indeed differences between Oracle JDK and OpenJDK, this in no longer true since Java 10, even less so in Java 16.
Now, Java like C or C++, enjoys multiple implementations, so even across OpenJDK, J9, Azul, PTC, Aicas,..., there will be differences.
Now, Java like C or C++, enjoys multiple implementations, so even across OpenJDK, J9, Azul, PTC, Aicas,..., there will be differences.
And that's why you have tests...
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.
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.
Are you serious? I've seen several large legacy Java applications move to OpenJDK without a problem.
> OpenJDK and Oracle Java are as different as Red-Hat Fedora and Red-Hat Enterprise Linux.
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.
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.
Whatever, the point being that since the last couple of releases OpenJDK and Oracle JDK differences are mostly about support, and license of using JFR in production.
I work at Oracle on OpenJDK (but I speak only for myself):
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.
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 suppose many of us (including myself) are waiting for Java 17 LTS release so that there's is a single migration phase (8 -> 17) rather than doing it now (8 -> 11) and also (11 -> 17) after few months.
upgrading from 8 to 11 is a good step to have. You will not believe how many problems pops up. Upgrading from 8 to 17 might be a very hard exercise - libraries and all..
I'd say that Java 8 -> 11 is going to be and order of magnitude more disruptive than 11 -> 17.
So if you have downtime now (ha ha), you might as well migrate to 11.
So if you have downtime now (ha ha), you might as well migrate to 11.
Why not put all versions of Java, including the master branch build, into your CI, then you can instantly see what it's possible to upgrade to, and instantly see when incompatibilities appear.
I don't really get what migration issues people experience in practice.
I don't really get what migration issues people experience in practice.
How much longer is Google willing to carry the OpenJDK7/8 baggage for Android? At what point does it become more economical to finally upgrade to Java 11?
[I don't do Android, but, ] isn't Google trying to kinda pivot to Kotlin?
Yes, however Kotlin builds on top of Java and its FFI to Java libraries is a selling feature.
It doesn't help much Koltin if those libraries can no longer be accessed with its FFI.
It doesn't help much Koltin if those libraries can no longer be accessed with its FFI.
Strange.... should the title be “You can’t afford NOT to run Java 8”?
How did you come to that conclusion? The point made is that Java 8 incurs costs compared to newer versions, so you need to "budget" for it. If you can't afford to not run it, then Java 8 would be saving you money/time somehow.
Because the first half of the article was praising Java 8 and it’s various benefits.
I didnt read the second half because I couldnt make sense of the negative headline with the positive text.
I didnt read the second half because I couldnt make sense of the negative headline with the positive text.
This is called "judging a book by its cover".
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.
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.
> the first half of the article was praising Java 8
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)
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)
The article is about the improvements since Java 8.
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.
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.
Thanks for the feedback! (author's here)
I promise to be more careful when picking up the title next time. I hope that the article's content somehow compensated that ;)
I promise to be more careful when picking up the title next time. I hope that the article's content somehow compensated that ;)
No, the author wants people to use versions higher than 8.
I thought the same thing at first. But Apparently there are newer versions of java. For those who learn java in school and don't much touch it again, it can be quite confusing.
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.
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.
Don't worry, all that's not getting widely used anyway. Cool startups don't touch Java anyway, and places like banks are still firmly at Java 8. My current employer is somewhat progressive, whole system is just a couple of years old, design is very much modern, microservices, event sourcing, reactive, cool reactive frontend on websockets, etc etc.
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.
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.
> For those who learn java in school and don't much touch it again, it can be quite confusing.
Is it really _confusing_? The idea that a product might change release cadence probably should not be confusing.
Is it really _confusing_? The idea that a product might change release cadence probably should not be confusing.
Well, the fact that all of the sudden there are all these new versions is surprising. That makes the title of the article confusing, because one doesnt expect that v8 is considered super obsolete.
The title paints Java 8 in a negative light, maybe change to "You can't afford to lag behind Java 8", or "You can't afford to not run Java 8+".
agreed; when I started reading this I thought they were saying if you are running anything below Java 8 it’s faster
Upgrading a Java 8 application is not easy if you have a very huge code base. The article focus on performance considerations, what about migration costs?
I'm a bit curious because of Java's story around backwards compatibility: what exactly makes a huge code base difficult to upgrade? You can use all the same byte code and just run it in a newer JVM.
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?
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?
There was a lot of proprietary sun stuff that got yanked out in the 8 -> 11 shift, along with the addition of the module system that makes reflection to hack into dependencies a lot harder (IIUC).
Upgrading 8 -> 11 is a lot harder than upgrading 11 -> 17 will be.
Upgrading 8 -> 11 is a lot harder than upgrading 11 -> 17 will be.
One example that comes to my mind: libraries that handle bytecode manipulation (e.g. javassist) may require to be updated because they give new and strange error if they meet newly introduced bytecode.
Since those libraries are often used by high level frameworks like Spring, this means that to move to a new Java version you have to update your framework.
These most often means new API, new bugs, new regressions...
These most often means new API, new bugs, new regressions...
I did a 6 to 8 migration at $lastjob. The upgrade was smooth except for 2 issues:
* 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?
* 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?
Just a quick shout-out to how far the language has come. Scala and Kotlin really lit a fire under Java's pants, and now the language is moving forward super-quick. Releases every 6 months, lambdas, fork-join, var, records, code looks and reads nicer, and the ecosystem is perking up too. Spring Boot, VertX, lots to look forward to.
Yeah, it's really disappointing to hear that the community isn't upgrading very quickly because the language is starting to look a lot nicer.
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 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 think one of the limiting factors is Android, which is still stuck with Java 8. So if you're developing a library, which in theory may be used in Android app by others, you have to stick to Java 8 to make it compatible.
I guess that's why Kotlin became so popular in the Android world - all the new & shiny features are present but you still can target older bytecode versions
Google is the one to blame, they let Android Java stagnate on purpose, after all it helps to sell Kotlin.
Kotlin is free though, and a JetBrains product, not a Google one.
Kotlin is married to Android, it doesn't go anywhere unless JetBrains settles for a divorce.
Actually, they've done a pretty decent job on multiplatforming it. Can use it for servers, compile to JS, even compile through LLVM and target iOS if that's your jam. Android is the killer use case, of course, but I think it'll survive losing preferred status on Android.
There are dozens of languages that have done exactly the same and eventually faded away.
Meh.... "if it ain't broken, don't fix 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
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
Of all the improvements in later Javas, I find the standard library upgrades the most impactful; things like immutable collections, collection factory methods, better ergonomics for streams and optionals, etc. It doesn't really fall strictly under "syntactic" improvements like records or 'var'.
I started upgrading some of the Docker images from Java 8 to Java 16 at work without touching the compiler. The changes I had to make to the code were fairly minimal, bump the version on a couple libraries and change the JVM flags on the Helm chart. The title is a bit clickbaity, but I agree with the premise for containerized workloads because the difference is huge.
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.
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.
Title should be changed to “You can’t afford to continue running Java 8”
That wouldn't necessarily be true though - some people could not afford to go through the work involved in upgrading from Java 8
oh I agree for sure; the title is just a bit confusing as is
Thanks for the feedback! (author's here)
Sorry to hear that it could be confusing. I will look at its contents once more soon looking for some improvements.
Sorry to hear that it could be confusing. I will look at its contents once more soon looking for some improvements.
I can't be the only person who read the title and thought: "oh no, what licensing quagmire has Oracle cooked up now?"
The title thesis here (which is that upgrading to the latest JVM from an older JVM will save a lot of money) isn't well-supported by the article, which doesn't really make claims stronger than "performance is somewhat better".
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.
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.
Thanks for the feedback! (author's here)
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.).
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.).
There's also the literal "can't afford" part. I assume there's a pretty high correlation of sites running Java 8 that are running Oracle's java.
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.
[1] https://java.com/en/download/release_notice.jsp
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.
[1] https://java.com/en/download/release_notice.jsp
Another reason is that a lot of companies use Java 8 internally and it makes it easier to use your software if you support 8.
I long ago left the enterprise Java world. I imagine that despite modern cloud computing, there are still many companies running ancient Java application servers--servers that have been running dozens of applications for years uninterrupted, save the occasional critical security patch. The teams that developed those applications are probably long gone. Upgrading the Java runtime would probably require licensing and installing a new version of the app server. Only then could they consider rebuilding the apps for a newer Java runtime and running through months of regression testing.
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.
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.
Its interesting to compare the general reluctance of the Java community to upgrading vs the Go community's preference to be on the latest version (or at most N-1).
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.
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.
I think there are two reasons why people haven't moved beyond Java 8:
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.
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.
There's another important bump in 10->11 which removed all of the bundled J2EE, so you have to add external copies of the removed libraries (if they exist; for instance, IIRC the CORBA stuff was removed without an external alternative). In my experience, these external copies have small subtle differences to the former bundled copy, which can cause some issues; though the biggest issue IMO is to find the correct external library name and version for each bundled J2EE library you depended on (and sometimes even which J2EE libraries you depended on, some things are loaded through reflection so it only fails at runtime).
People were really bad about upgrading off of Java 6. That was pretty terrible if you operated a TLS endpoint and wanted to drop old insecure configuration options. Sorry, you've got some ancient Java 6 clients that only supports DH 1024.
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.
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.
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.