Analysing Regression impact from migration to Azul Zulu Open SDK from Oracle Java

Question

I have a Spring MVC application which was using the following dependencies

1. p4java (version - 2019.1.1873579)
2. sardine (version – 129)
3. commons-httpclient (version – 3.1)
4. org.w3c
5. org.xml

Edit: I am migrating from Oracle java version "1.8.0_202" to openjdk version "1.8.0_241"

But I have to now migrate from Oracle Java to Azul Zulu Open SDK. Are there any known issues with the above dependencies with Azul Open SDK. I tried looking for the same but could not find any information on this. How do I analyse if there could be any regression issues due to this migration.

Answer 1

Since the Oracle JDK is built from OpenJDK just as Zulu is, there will be no functional differences that would affect an application. Both are also TCK tested, ensuring that the builds conform to the Java SE specification.

However...

If you migrate from Oracle JDK 8u202 to Zulu 8u241 there will be differences due to the inclusion of various security patches and bug fixes between u202 and u241.

A couple of suggestions:

1. Initially, migrate from Oracle JDK 8u202 to Zulu 8u202 (which can be found here: https://cdn.azul.com/zulu/bin/). That way, you will be testing like-for-like and can feel confident the Oracle and Zulu runtimes are equivalent.
2. I'm not sure why you would migrate to update 241. The most recent (from last week) is update 292. For maximum stability and security of your application, you should really be using the latest update.

Answer 2

I tried looking for the same but could not find any information on this.

There are no comprehensive resources on regressions between different Java vendors' offerings:

• because such regressions are rare to non-existent, and
• because migration from one vendor to another other is unusual.

The thing is that most Java vendors are working from the same OpenJDK codebase, and running the same standard regression testsuite. While some vendors will be tracking a little behind the OpenJDK patches, I wouldn't expect much of a delay, especially for important changes and fixes. And everyone is trying to not break people's Java application code ... because it causes reputational damage for the Java vendors.

If we exclude clearly advertised vendor differences / differentiation, you are (IMO) more likely to run into differences between different OpenJDK Java versions and updates, than you are between matching versions / updates provided by different Java vendors.

For example, I see that in "1.8.0_291" they have disabled TLS 1.0 and 1.1 ... which might require remediation if your application still needed to support these (insecure) versions of SSL / TLS for legacy reasons.

So, given that ...

I am migrating from Oracle java version "1.8.0_202" to openjdk version "1.8.0_241"

... you are more likely to run into problems from the "_202" to "_241" changes than from the Oracle Java to Azul Java change. If you are really concerned by the possibility of regressions, I would recommend treating this as two separate migrations. And then try to keep up with the patches. You shouldn't have allowed yourself to get 27 months behind on updates, especially since one of the intermediate patch releases ("_231") contains a batch of security fixes.

---

How do I analyze if there could be any regression issues due to this migration.

My advice: Don't try to analyze it. Just try the migration, test it thoroughly to see what (if anything) breaks, and fix it.

Obviously, you need to be able to test thoroughly before you roll your migrated application into production.

But that is pretty essential anyway. No matter how much "analysis" you do, you can't eliminate the possibility of regressions that might affect your application.