Unsupported Versions of Java Are Dangerous
Java 7 is still a great Java deployment platform
Last month Oracle released JDK 19, with exciting new preview features like virtual threads and structured concurrency (both part of Project Loom).
However, most users do not want to upgrade their Java runtime every six months, choosing instead to wait for the next long-term support (LTS) release. The adage “if it ain’t broke, don’t fix it” is often applied to deployed applications. As a result, almost all production enterprise applications (including mission-critical ones) are still running on older versions of Java. Sometimes very old… Sometimes unsupported versions of Java.
With long-term support (LTS) releases, users can rely on specific Java versions continuing to have regular security and bug fix updates so their applications remain as secure and stable as possible. Although all OpenJDK distributions are aligned on the same LTS versions, the provider determines how long a particular distribution will be supported.
| Java Version | Release Data | End of Extended Support |
|---|---|---|
| Java SE 6 | December 2016 | Oracle – Ended December 2018 Azul – December 2027 |
| Java SE 7 | July 2011 | Oracle – Ended July 2022 Azul – December 2027 |
| Java SE 8 (LTS) | March 2014 | December 2030 |
| Java SE 9 | September 2017 | – |
| Java LTS 10 | March 2018 | – |
| Java LTS 11 (LTS) | September 2018 | September 2026 |
| Java SE 12 | March 2019 | – |
| Java SE 13 | September 2019 | – |
| Java SE 14 | March 2020 | – |
| Java SE 15 | September 2020 | – |
| Java LTS 16 | March 2021 | – |
| Java SE 17 (LTS) | September 2021 | September 2029 |
| Java SE 18 | March 2022 | – |
| Java SE19 | September 2022 | – |
If you’re in the unfortunate position of using JDK 5 or earlier, there isn’t anything you can do to keep your applications as secure as possible other than migrating to a newer version. OpenJDK was created in 2006 with JDK 7; there is an OpenJDK 6 project that was JDK 7 retrofitted to conform to the relevant specification.
Oracle recently ended extended support for OpenJDK 7, making it particularly topical. If you are using JDK 7 to run applications, you are now faced with three choices.
Choice 1 – Use JDK 7 unsupported
The first is to continue using JDK 7 without any further updates. It can’t be overstated how dangerous unsupported versions of Java are. OpenJDK has four scheduled updates per year in January, April, July and October. These include patches for any security vulnerabilities reported and addressed since the last update. Although Java is over 27 years old, it is simply not possible to state categorically that there are no more vulnerabilities. Since the JDK is built using external libraries, such as those of the host operating system, vulnerabilities can also be found in those. Since the end of free public updates to JDK 7, 260 CVEs (common vulnerabilities and exposures) have been addressed specifically for that version If you want an example of why running out-of-date software is dangerous, look no further than the example of how Equifax got hacked.
Choice 2 – Upgrade your Java version
The second choice is to upgrade to a newer version of Java that distribution providers are still maintaining. Although Java has excellent backward compatibility, this option is not without its challenges. If you choose to move to the latest LTS release, JDK 17 (or even the one before, JDK 11), you will have to address the significant changes from JDK 9. JDK 9 introduced the Java Platform Module System, which substantially changed how the JDK is packaged for distribution. Even more important was the encapsulation of internal APIs in the JDK to make the public APIs work. Probably the most famous (or infamous) of these is sun.misc.Unsafe. If your application uses any of these APIs, then you will need to identify which classes have been used (either directly or through reflection) and configure the command line flags to enable access to them. Your code may not use these APIs directly, but any third-party libraries and frameworks you use probably have. All of this requires work. More importantly, it requires thoroughly testing your applications to ensure they work the way they did on the older version.
Option 3 – Switch to a distribution that supports JDK 7
The third and simplest option is to continue using JDK 7 but switch to a different distribution that still provides regular updates with all relevant security patches and bug fixes. JDK 19 has numerous features that don’t exist in JDK 7, so these are irrelevant to JDK 7.
According to the JRebel 2021 Java Developer Productivity Report, 15% of Java developers still use Java 7 or earlier unsupported versions of Java. If option three sounds appealing, then Azul is here to help. We have committed to continue delivering the quarterly updates to JDK 7 until at least December 2027 through our Azul Platform Core product. This gives you over five years before you need to worry about what to do for these applications. In addition to the scheduled updates, Platform Core also delivers two versions of each update, one that includes just the security-related patches and one for the full update. The benefit of having the security-only update is the ability to deploy this as quickly as possible if critical vulnerabilities (a CVSS score of 9.0 or higher) are identified, and you need to deploy the update as promptly as possible. Should you need help, Azul has an expert support team with a hundred per cent customer satisfaction rating.
All your enterprise applications should be as secure and stable as possible, even when using older versions of the Java platform like JDK 7. Why not find out more?
The post Unsupported Versions of Java Are Dangerous appeared first on Azul | Better Java Performance, Superior Java Support.
*** This is a Security Bloggers Network syndicated blog from Security Blog Posts - Azul authored by sritter. Read the original post at: https://www.azul.com/blog/unsupported-versions-of-java-are-dangerous/
