Le 28/09/2021 à 08:52, Johan Vos a écrit :
Having said that, I really want to focus on the original technical
questions. I appreciate the concerns about the general position of Java,
but in an OpenJDK context, I believe it is best to stick to the
technical "details" and just make it happen.
I believe the first step is to list the technical features we would like
to have, and then see if it's feasible and how.
Here is my take:
1) Parts of a maven artifacts can be specific to
- a system
- an arch
- a flavor (or whatever better name you prefer). For instance : cpu
only/gpu, with MKL or OpenBLAS, optimized for some instruction set or
not, with some option set during compilation or not...
or to any combination of those 3.
Example : some system-specific java code, a native library for a
specific system/arch/flavor.
2) This parts should be made available separately in different
containers (probably jars as maven classifiers) to avoid duplication.
3) at DEVELOP and BUILD time, developers should not have to bother about
a system/arch/flavor.
4) at RUN time, developers/users should be able to choose a specific
flavor if they need to (or some default flavor from the available ones
would be used).
5) at RUN time, the JDK should handle the extraction of the proper
native libraries to the file system, where System.loadLibrary (or the
future Panama replacement if any) can find them, and load the proper
Java classes, when they are needed.
6) at PACKAGE time, developers/integrators should be able to choose
which (possibly multiple) system/arch/flavor to bundle.
7) at PACKAGE time, jlink should pre-extract the native libraries in the
image and strip them from the containers/modules.
--
Hervé Guillemet
