1. Old version, and security updates are still required
There's some critical piece of legacy software that has only been tested and observed to work on an old version of the JVM (e.g Oracle JDK 8).
The cost of decommissioning the software OR upgrading and re-testing on a later JDK OR switching to the OpenJDK (without security updates...) is perceived to be more expensive or in breach of company policy versus paying licensing fees.
2. Use of proprietary or deprecated APIs
Either company code or that of a library dependency has reliance on proprietary or undocumented Oracle (or Sun) APIs and toolkits that aren't supported in OpenJDK.
The chances that the existing team members, or the current army of "Spring Boot Microservice Developers" will be able to rationalise or unwind this code in a reasonable time frame is slim.
Though to be fair I haven't seen #2 in some time now.
Some people feel it's more "original" or "pristine" build. Oracle develops Java, surely they know better how to build it and surely they'll patch it before others.
Though at that point I wouldn't touch anything Oracle with a long pole.
It used to have some differences in UI and text rendering because those components could not be open sourced. Now they are effectively the same for the current version, but obviously older versions may differ in the number of security or performance fixes that get
Back ported.
Don't know about now, but many versions ago, Android Studio, just doesn't not start in OpneJDK. It is mainly the UI my guess is. It requires one to install OracleJDK to work. Don't know if it is still the case or not. For most headless stuff, I would image there shouldn't be any difference.
Do you have examples? I haven't seen any in a decade and now OpenJDK is almost the same as any vendor JDK, with small exception of bugfixes that might be included in given vendor JDK before it is merged back to OpenJDK repo.
I had the displeasure of working with Cisco ASDM software, which specifically didn't work with it. Maybe that's different now, but back then even their purported 'openJRE' versions were garbage.
1. Old version, and security updates are still required
There's some critical piece of legacy software that has only been tested and observed to work on an old version of the JVM (e.g Oracle JDK 8).
The cost of decommissioning the software OR upgrading and re-testing on a later JDK OR switching to the OpenJDK (without security updates...) is perceived to be more expensive or in breach of company policy versus paying licensing fees.
2. Use of proprietary or deprecated APIs
Either company code or that of a library dependency has reliance on proprietary or undocumented Oracle (or Sun) APIs and toolkits that aren't supported in OpenJDK.
The chances that the existing team members, or the current army of "Spring Boot Microservice Developers" will be able to rationalise or unwind this code in a reasonable time frame is slim.
Though to be fair I haven't seen #2 in some time now.