I have a Spring MVC application which was using the following dependencies
- p4java (version - 2019.1.1873579)
- sardine (version – 129)
- commons-httpclient (version – 3.1)
- org.w3c
- 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.
There are no comprehensive resources on regressions between different Java vendors' offerings:
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 ...
... 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.
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.