![]() Don't get me wrong, we use Java 11 on a lot of things but there's very little impact on our day to day coding. Most of the stuff in Java 11 (which as I said, is the only Long Term Support version after 8) isn't a HUGE deal. So that further reduces the incentive to upgrade. Furthermore, there are now good Open JDK releases from 3rd parties that provide decent support for Java 8 even though Oracle doesn't. Also the problems broken by Java 9 won't be fixed so the incentive to upgrade is reduced. Newer versions aren't as bad but the trend of breaking super strict compatibility was set and updating removes the incentive. It broke so many things we're still licking our wounds years later. (Note that Java 11 is a long term release which is supported until Java 17). So the only people using Java versions other than 8 and 11 are people who don't mind things breaking as much. This isn't practical for most (all the ones I know at least) companies. So if you upgrade you must upgrade immediately when a release is made. As part of that releases don't get support when a new one comes out. Oracle switched to fast release cycle with Java 9. For some newer projects, I already use JDK 16 because a lot of new useful features were added. Since many projects are still on Java 8, most libraries maintain JDK 8 compatibility even if updated for JDK 11+ compatibility.Īs a library maintainer, I also made sure to be Java 8 compatible (this will change at the latest when JDK 17 is released because keeping JDK 8 compatibility is slowing my development).īut for applications, I require at least JDK 11 (if my client doesn’t have at least JDK 11 installed, I bundle a Java runtime). Also, some deprecated methods have finally been removed, and dependencies have to be updated because some JEE classes are not distributed with The JDK anymore. To be clear: this is in most cases the library maintainer‘s fault. ![]() Large projects rely on libraries that are still not fully compatible with newer Java versions because they depend on implementation details that are not accessible any more, or have changed. Compared to that, even going from 9 to 16 is in most cases a piece of cake. While newer versions of Java have a lot of nice features, if you don't really need those features, there's not really that much incetive to update your code to use a newer version of Java.įor sufficient complex projects, the switch from Java 8 to 9 is much harder to do than any of the later updates. So apps may want to focus effort on other things, like new features or fixing bugs, rather than migrating from a version of Java that's working perfectly fine now and for the foreseeable future. Migrating a lagre codebase can be very painful. All other versions generally only receive updates until the next version is released. The next version of Java, Java 17, is also scheduled to be a long-term supported release. While there have been many new versions of Java since Java 8, only one (Java 11, in 2018) has been a long-term supported release. ![]() Java 8 is scheduled to continue to receive security updates until 2030. Java 8 was the latest long-term supported version of Java between 20, so many apps would have started with or migrated to Java 8 during that time. I can imagine there being a number of reasons why apps may still be using Java 8: Nobody cares that it's now Rust 1.50 or whatever. Rust does a release every 6 weeks and I think that works great. Honestly, I almost wish they'd move to an even faster release model to really force people to stop caring so much about these version numbers. Post Java 9, the upgrades have been a breeze. Further, it's allowed them to slowly walk in huge features (Valhalla, loom, etc) making pre-emptive changes needed to support massive changes in the future. A ton of usability features made it in (records, pattern matching, string literals) which never would have made it in the old model. With the new model, they've been able to work on a lot more features in parallel. Further, releases where crazy times for JDK developers. The problem with that is nearly all project development got devoted to that feature and ultimately "when" java would go out was completely unknown. It used to be that they'd say "Ok, we are going to target key feature X for java Y". People bitched about version numbers but slowly got use to the fact that "I don't really care that this is firefox 82".įrom an organization standpoint, this has been great for the Java getting features out. Same thing happened when Firefox and chrome switched to a timed release model. Because they switched to a new release model which allows for them to get new features out faster. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |