On 23/04/2019 22:53, Sciampacone, Ryan wrote:
Agreed on the changes since JDK9.
This specific problem doesn't exist in jdk/jdk because even in a (for my
example, linux) product image, although FileSystems isn't touched,
sun.nio.fs.UnixNativeDispatcher gets initialized as part of startup - this
clears up the native library load (nio) collision that could occur through that
class. This is the case we see customers experiencing. Preloading
FileSystems.getDefault() in jdk8 is a mostly inert and friendly (not reaching
into the bowels, letting the platform pick the right class) way of getting that
problem out of the way.
You can see the corresponding stack traces here that highlight the issue:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050819.html
I realize you are running the issue with JDK 8 but I think we do need to
investigate the main line a bit more too. You are correct that the file
system is initialized early in JDK 9 but this isn't the case for JDK 10
and newer due to further work to reduce startup time. The stack traces
in the bug report look like they may have been taken with an exploded
build or with --patch-module, just two of several cases where it might
be initialized early. I think it will be harder to demonstrate an issue
with JDK 10, esp. if there are JAR files on the class path as any access
to JAR files will trigger the file system to be initialized.
-Alan
