Hi. I’m Michael. Welcome back to the Oracle Java Recovery Network, where healing from Oracle Java begins. As we covered in our first meeting, we guide organizations who feel trapped by long-term Oracle Java agreements and ongoing price changes through a structured six-step program. Today we’re talking about knowledge and action in choosing an OpenJDK distribution.
Knowledge: Your fears of migrating from Oracle Java are unfounded and there are better Java partners out there. New evidence demonstrates that migrating to an OpenJDK distribution is often easier and less time-intensive than technology leaders expect, and that your companies usually save on support costs after switching to an OpenJDK alternative to Oracle Java.
Action: You are ready to start life after Oracle Java and begin your migration to OpenJDK with a partner you can trust. Start preparing now by creating an inventory of your Java distributions and versions, before your expensive Oracle Java license renews
Knowledge is the key to effective action
My friends, the time has come to select an OpenJDK distribution. Here’s some good news: Migrating from one JDK distribution to another is often easier than expected — provided both distributions have passed Oracle’s Technology Compatibility Kit suite of tests. TCK tests prove a distribution conforms to the specifications of the Java SE standard. Distributions that pass all the tests for a particular version are functionally equivalent and can be swapped for each other, literally by changing the pointer in an application.
Follow the path, my friends. Azul Deputy CTO Simon Ritter explains Azul’s proven OpenJDK migration process in his book, OpenJDK Migration for Dummies. Migrating to certified builds of OpenJDK can be straightforward for most enterprises. If you’re migrating server applications, you’re unlikely to encounter any challenges.
According to the 2024 Oracle Usage, Pricing and Migration Survey & Report, roughly two-thirds of survey participants who plan to migrate off Oracle Java to an OpenJDK distribution (but haven’t started yet) plan to start their migration within two years. In other words, you are not alone.
There is urgency to act
There is urgency to migrate. The first is the end of Oracle’s free commercial support for Java 17, and the second is the end of JavaFX 8 in Oracle Java SE.
- Java 17: Oracle releases a new Long Term Support (LTS) Java version every other year. If you have an Oracle subscription, you can use an LTS version for free until one year after the next LTS is released. Oracle released JDK 21, the current LTS, in September 2023. Which means that on October 1, Oracle Java 17 transitions to a license that no longer allows free commercial and production, including access to quarterly security updates.
- JavaFX 8: Oracle will end support for JavaFX in JDK 8 in March 2025 and will stop providing Java 8 builds with OpenJFX included, as explained in the Oracle Java SE Support Roadmap. Starting in April 2025, if you are using JavaFX you will need to find an alternative distribution to continue to receive security updates. If you continue to use JavaFX 8, your CI/CD builds will fail as new Oracle JDK 8 versions no longer support JavaFX. You can’t fix these failing builds as JavaFX 8 is no longer maintained as an open-source project, and no separate downloads are available.
Start building your Java inventory now
Every organization has a unique application infrastructure. Java lurks almost everywhere because of its longstanding role in applications, hardware, deployment types, and cloud vendors. Establishing accurate Java licensing risk requires an in-depth and up-to-date Java estate inventory. It’s especially crucial to capture details like Java versions that require paid Oracle Java SE subscriptions.
Start with an Oracle-approved IT asset management (ITAM) or software asset management (SAM) tool, like SHI, Flexera, or Certero. While these tools help you comply with license terms and conditions, they can also produce reports showing which machines installed which versions of Java.
Conclusion
Inventory Java in all applications, devices, and middleware across all deployment types. For licensing and migration purposes, you must know which Java versions are used by which applications and on which machines, including cloud instances. You must identify unused Oracle Java versions so you can delete them. If Oracle finds them, they’ll count against you.
Be aware of which use an auto-updater because an inadvertent update could have terrible consequences. Good luck on your journey.
