Is the Cost and Complexity of Removing Java Worth It?

Oracle Java’s licensing and pricing challenges are pushing companies to explore alternatives. Many are considering migrating to an OpenJDK distribution, and some are even considering removing Java in favor of another programming language. Azul Deputy CTO Simon Ritter presents a clear view of the real risks and benefits involved in moving your entire application estate off Java. 

Removing Java can be a complex process, given the pervasive nature of the programming language and toolkit across your applications and infrastructure. In a landscape where Oracle Java’s licensing and pricing challenges are pushing companies to explore alternatives, many are considering migrating to an OpenJDK distribution. 

However, some companies have even gone as far as to consider refactoring their business applications to another programming language to simply avoid the risk and ongoing uncertainty presented by Oracle. With four licensing and pricing policy changes in four years, that uncertainty is unlikely to stop any time soon. 

Here is a clear view of the real risks and benefits involved in choosing to move your entire application estate off Java so that you can be properly informed of the impacts and impractical nature of this decision.

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. Aside from the fact that Java is the incumbent for most enterprise applications due to its proven speed, scale, stability, security, and quarterly feature enhancements and upgrades, it’s also a core skill of the developer workforce at most organizations. Refactoring and starting over would have serious consequences for your in-house application programmers, as teams would either need to learn alternative programming languages or be replaced.

Putting all that aside, removing Java can be a complex process, given the pervasive nature of the programming language and toolkit across your applications and infrastructure. 

For instance, popular frameworks and tools like Spring, Struts, Google Web Toolkit, Grails, Vaadin and Apache Log4j all depend on the Java Development Kit (JDK) 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 would 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 you still 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 difficult, 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 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 might 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. 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. Replacing Java with a different language, however, is much trickier 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 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 affects 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 (Technology Compatibility Kit)-certified OpenJDK distributions available, including Azul Platform Core.

A version of this article originally appeared in The New Stack.