Modules with platform specific parts
Mike Hearn
mike at plan99.net
Tue Sep 28 08:20:42 UTC 2021
To get back to technical aspects, the sub-question of native code loading
from JMODs/JARs has come up before. In 2018 I did some experiments with
loading native code directly from memory (i.e. a JAR) on different
operating systems, and wrote up the results here:
https://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-April/013762.html
Linux had the best support, Windows was a runner up and macOS didn't
support it at all - you'd have to just write it out to disk and reload.
Dependencies between multiple native libraries was an open question. The
JVM is flexible, and since 2018 Panama has done a lot of work to improve
the internals of native code loading. It would be easy to make some
prototypes of different approaches now. Jigsaw seems to be de-staffed so
it's very much a case of "he who codes, wins" at this point - I don't think
the Java architects are going to descend from a throne and issue a
recommendation, given that the JDK and JavaFX already picked their own
approach (SDKs with your approach 1).
It may be worth taking a step back and asking to what extent is this need
driven by inadequate build tools, vs a true lack in the Java platform
itself. If Maven/Gradle worked better and the repository format more
supportive of platform-specific modules, would these four different
patterns matter at all? Put another way, what stops the JDK itself being
hosted entirely on Maven Central? If those tools more fully embraced the
jlink model then a lot of these questions and SPI-related busywork would go
away.
More information about the jigsaw-dev
mailing list