Question regarding OpenJ9 and Microsoft Differences

[jim-doyle]

Could someone summarize the differences between the recently opened J9 Port (IBM) and this current MicroSoft Endeavor and tell what what the roadmap is?

Couple of things about J9.

1. It has IBM Heritage with its own Memory Management / Heap Framework which is entirely different than HotSpot. Some of the IBM Diagnostic Tooling is very appealing to those lucky enough to have used in an IBM Shop and having been trained on using it (i.e. MAT). As a result, we are now using J9 on Linux on production - having moved off HotSpot with the Oracle licensing gimmick. The folks I work with are excited by the IBM-isms and particularly the Memory Analyzer Tool with the enhanced WebSphere packs. We are not an IBM product shop, but the JVM is better choice for us. That said, is Microsoft taking on the IBM parts, or the Sun parts?

2. IBM never intended J9 to be run on Windows. They provided a "bastard child" of their VM on Windows strictly for Developers running Eclipse developing on WebSphere.... For Decades, their expertise on J9 was marrying it to Linux and further, to z/Architecture and POWER where Hardware Assists to the JVM made it very appealing. However, that said, OpenJ9 is a relatively Recent Windows 10 Port. Clearly Microsoft would have not only the expertise, but the access to provide Windows Kernel extensions that might provide better performance and perhaps better monitoring/diagnostics than what a plain-jane POSIX port might look like.

That said, I assume the Microsoft OpenJDK will be positioned as the De-Facto Best on Windows, just as OpenJ9 would be for AIX on Power, or Linux on z/OS. That said, what is the Roadmap for features that will distinguish it over the other OpenJDK features?

[karianna]

Hi @jim-doyle - The MSFT Build of OpenJDK is a regular OpenJDK distribution (Hotspot based) in the same vein as Oracle JDK, Azul Zulu, Amazon Corretto et al. When it comes to platform support Microsoft will be supporting Linux, Mac OS X, and Windows equally.

As a default, we have an upstream all patches policy. That is, assuming we discover any major performance/stability regressions that impact our customers whether that be on Windows, Linux, or Mac OS X, we'll naturally work with our partners at OpenJDK to land a patch for the whole Java ecosystem to benefit from. The only exception to this is if a risk-averse upstream repository (jdk8u or jdk11u for example) won't accept the patch, in which case we'll make that patch available in our GitHub source repository, and have that patch as part of our MSFT Build of OpenJDK (clearly sign posted in the release notes).

Hope that helps!

[jim-doyle]

I see, so this is more of another Hotspot style build that is vetted and tested for Windows 10+ and Azure platforms.

The two things we worry about is (1) Performance Monitoring, Profiling the Troublshooting Tools and (2) Security.
For the Security part, we have to manually intervene with JRE installation to (1) setup the PKCS11 hooks for Certificate and Key Management and (2) access to a vetted CSRNG source.

For the Security side, it would be nice to use Windows Certificate Management facilities rather than moshing about keystore/truststore files by hand and worrying about file permissions and KEKs and trust chains being in the file etc..