search

OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.16k stars 592 forks source link

IBM JDK 1.8.x reports vendor as Oracle on macos #16366

Open frowe opened 3 years ago

frowe commented 3 years ago

When the kernel service JavaInfo class is used on an IBM 1.8 JDK for macos, it reports the vendor as Oracle, not IBM because System.getProperty returns IBM. java -version reports Java(TM) 2 Runtime Environment, Standard Edition (IBM build 1.8.0_271-b09 19_Nov_2020_11_04 Mac OS X x64(SR6 FP20)) The JavaInfo class reports:

vendor:ORACLE
major version:8
minor version:0
micro version:271
fix pack:20
SR:6

String vendor = System.getProperty("java.vendor").toLowerCase(); reports java.vendor:oracle corporation

The vendor matters to code like JDBC, security and LDAP that interface with kerberos. My team made an update to some of the code we delivered for Liberty kerberos support late last year to work around this. Our fix to differentiate the vendor is to try to load the krb5LoginModule for IBM (see Krb5LoginModule.isIBMLoginModuleAvailable()), if it succeeds, consider the JDK an IBM one. Since many project already depend on kernel service, updating the behavior there would be preferable to having to do it in numerous places elsewhere. Technically, this is probably a JDK bug, but even if fixed by the JDK, we're going to spend a lot of time debugging issues on the non-patched versions of the JDK, so if we can add some flexibility in detection of vendor, it would be helpful.

brenthdaniel commented 3 years ago

This is actually a little tricky... The vendor in this case actually is Oracle. IBM doesn't produce it's own version of the JDK on Mac/Solaris/HP-UX, but rather has a "hybrid" version that takes the oracle JVM and adds IBM orb, security, and xml jars. This approach is only applicable to 1.8.

I think, in terms of the utility, returning "oracle" as the vendor is probably correct. There may be some value in adding another method that attempts to determine whether IBM jars are available, but it might make sense to allow individual components to make this determination as needed.

frowe commented 3 years ago

Ok, I agree with the analysis, and I agree there's value in adding a utility method to determine whether it is a hybrid JDK, otherwise we'll continue to have lots of impls spread throughout component code.