Moving Off Java Is Probably Not Worth the Effort or the Risk

Azul migration experts researched reasons companies choose not to migrate from Oracle Java to an OpenJDK distribution. After careful investigation, they identified six Oracle OpenJDK migration myths and produced the facts to counter each one. 

Myth 1: It’s easier to get rid of Java than to deal with Java’s licensing and pricing risks. If Oracle is creating a problem over Java, remove the source of the problem and use an alternative programming language. 

Reality: It’s very difficult to get rid of Java. Rewriting your code can take years, and there is an inherent risk that the code will not deliver the same functionality and possibly contain new bugs. Organizations that seriously look at rewriting in a different language typically conclude that better, more affordable alternatives exist.  

If Oracle’s pricing, licensing, and enforcement tactics become too onerous, some companies may be tempted to throw up their hands and to consider removing Java completely. However, removing Java can be a complex process, as Java is often used in a variety of applications and can include many dependencies. 

Popular frameworks and tools like Spring, Struts, Google Web Toolkit, Grails, Vaadin, and Apache Log4J all depend on the Java Development Kit that is the heart of “Oracle Java.” Web servers like Apache Tomcat, Jetty, and Wildfly/JBoss depend on the JDK.  So does infrastructure like Kafka, Hbase, and Solr.  Each of these programs has benefits that will have to be replaced in another language, and you will want to verify that the switch will be worth it. 

 If you need to get off Oracle Java before Oracle moves you onto an expensive licensing plan, it’s time to find an affordable alternative to Oracle Java SE, that offers version-for-version compatibility and the same timely updates. 

If instead you choose to proceed with removing Java, here are some challenges you will need to overcome: 

Why is removing Java so hard? 

Here are some typical challenges when removing Java from a production environment: 

• Identify all the applications that rely on Java: This can be a difficult task, especially in large and complex environments. Review application inventories, interview application owners, and scan systems for Java applications. You can also search for Java keywords such as class, interface, method, and variable. 

• Update applications to use another programming language or platform: This can be a time-consuming and expensive process. Refactoring code –introducing incremental changes that improve readability or interoperability without changing how the code works – can be complicated,. Completely rewriting code in another language is an undertaking that could take years, depending on the amount and the complexity of the environment. 

• Test applications to ensure that they still work on the new language: This is important to avoid disrupting critical business applications. Determine whether the application will continue to function without Java and identify any potential risks or disruptions that may occur from removing Java. Java code has dependencies on Java-based libraries and applications. 

Reduce risks in an OpenJDK migration 

Organizations can take steps to reduce the risk of something catastrophic happening. These steps include: 

• Create a backup of the environment: This will allow you to restore the environment if something goes wrong. 

• Remove Java from one server at a time: This will help you to identify and resolve any problems before you remove Java from the entire environment. 

• Monitor the applications after Java is removed: This will help you to identify any problems that may occur. 

• Replace the Java code with equivalent code in another language: This can be done by using a code converter or by manually writing the code. 

• Test the code to make sure that it still works: This can be done by running the code and checking for errors. 

The art of refactoring Java code 

As noted above, refactoring Java code carries risks and takes time. Completely refactoring code to enable the removal of Java can take years in a complex environment. Most large enterprises will find themselves refactoring code from multiple Java distributions and versions. 

Companies staying on Java probably have people who know the code well to do the refactoring. When replacing Java with a different language, however, is much tricker and could require an influx of new talent or a team of contractors. Either path is potentially expensive, time-consuming, and risky. 

Dealing with Java dependencies 

Java dependencies can make removing Java difficult because Java applications often rely on many different libraries and frameworks. If one of these dependencies is removed, it can break the application. Circular dependencies can cause issues including tight coupling of the mutually dependent modules, which impacts the ability to use each module separately. 

Here are some specific reasons Java dependencies can make removing Java difficult: 

• Version conflicts: Different versions of a library may not be compatible with each other. If you remove a library and replace it with a newer version, you may need to update other libraries in your application as well. 

• Missing dependencies: If you remove a library that other libraries in your application depend on, those libraries will no longer work. You will need to find and install replacement libraries for all of the missing dependencies. 

• Circular dependencies: Two libraries may depend on each other. If you remove one of these libraries, you will also need to remove the other library. This can create a chain reaction, where you need to remove more and more libraries until you have removed all the circular dependencies. 

There are a few things you can do to make it easier to remove Java dependencies: 

• Use a dependency management tool: A dependency management tool can help you track which libraries your application depends on and which versions of those libraries are compatible with each other. 

• Use a build tool: A build tool can help you automate the process of updating and removing libraries. 

• Test your application thoroughly: Before you remove a library, make sure to test your application thoroughly to make sure that it still works. 

Conclusion 

The difficulty of removing Java from a company’s production environment depends on many factors, including the size and complexity of the environment, the number of applications that rely on Java, and the level of expertise of the IT staff. In general, removing Java from a production environment is a complex and time-consuming process. It is important to carefully plan and execute the removal process to avoid disrupting critical business applications.

Remember too that Java remains one of the most popular programming languages in the world for its flexibility, ease of use, and interoperability. In the Azul State of Java Survey and Report 2023, 98% of respondents use Java in their software applications or infrastructure, and 57% say most of their applications are Java-based. Compound this number by Java-based frameworks, libraries, and JVM-based languages and it’s clear Java continues to play an instrumental role in the modern enterprise.

Does the difficulty of removing Java mean you must deal with Oracle for your Java needs forever? Certainly not. There are many TCK-certified OpenJDK distributions available, including Azul Platform Core. And while Oracle might have you believe migrating to another Java provider is prohibitively difficult and expensive, Azul Deputy CTO and Java Champion Simon Ritter literally wrote the book on OpenJDK migration. Learn more about Azul Platform Core and how to migrate safely from Oracle Java to a trusted OpenJDK alternative.