DOCS: Describe granting native library access - #563
Conversation
Documents --enable-native-access for classpath and module path setups, following the module names added in pipeline-java for #476.
justadreamer
left a comment
justadreamer
left a comment
There was a problem hiding this comment.
do we perhaps need to also name modules in device-detection-java too? not only in pipeline-java?
justadreamer
left a comment
justadreamer
left a comment
There was a problem hiding this comment.
requesting changes so the PR does not merge automatically
JEP 472 checks JNI method binding against the module declaring the native methods, which is this package rather than pipeline.engines.fiftyone, so both names are needed. Documents granting native access on the classpath and the module path. Implements #476.
Adds Automatic-Module-Name to device-detection, device-detection.cloud and device-detection.shared. Only the on-premise engine needs a name for native access, but without a declared name the module system derives one from the file name, which changes if the artifact is renamed or shaded. Implements #476.
Yes - and more of them than I first had. Done in the latest push. Needed.
All 264 Worth doing anyway. I have named the other three as well, because without a declared
The derived names are what anyone putting these jars on the module path gets today, and Checked there are no split packages between the four, so the distinct names are safe. The jars stay ordinary non-modular jars - One thing I could not verify: the JNI binding warning itself. Only JDK 17 is available The companion pipeline-java PR (51Degrees/pipeline-java#106) has been reworked to |
--module-path takes directories or jar files; the "*" wildcard is a class-path-only feature of the launcher, so "mods/*" found nothing and the command failed with FindException on the module named by --add-modules.
2 participants
Device detection half of #476.
JEP 472 restricts two operations that on-premise device
detection needs, and they are declared in different repositories:
System.loadpipeline.engines.fiftyonefiftyone.pipeline.engines.fiftyonenativemethodsdevice-detection.hash.engine.on-premisefiftyone.devicedetection.hash.engine.onpremiseAll 264
nativedeclarations in this repository are inDeviceDetectionHashEngineModuleJNI, so granting only the pipeline module would leave asecond warning coming from device detection's own code.
Changes
Adds
Automatic-Module-Nameto all four packages. Only the on-premise engine needs onefor native access; the rest are named so that the name stays stable for anyone who puts
them on the module path, rather than being derived from the file name:
fiftyone.devicedetectiondevice.detectionfiftyone.devicedetection.clouddevice.detection.cloudfiftyone.devicedetection.hash.engine.onpremisedevice.detection.hash.engine.on.premisefiftyone.devicedetection.shareddevice.detection.sharedAlso adds a Native library access section to the README covering the classpath case
(
--enable-native-access=ALL-UNNAMED, unchanged and still the default), the module pathcase naming both restricted modules, and the module name table.
No source changes.
Automatic-Module-Nameis a plain manifest entry, so the jars stayordinary non-modular jars, build identically on every JDK from 8 upwards, and nothing
changes for consumers who stay on the classpath.
Verification
Built offline with
-DskipNativeBuild=true; all four manifests confirmed withjar --describe-module. Checked there are no split packages between the four packages,so the distinct names are safe.
Not verified: the JNI binding restriction ships in JDK 24 and only JDK 17 was available,
so the second module name is added on the basis of where the
nativedeclarations liverather than an observed warning.
Depends on the companion pipeline-java PR (51Degrees/pipeline-java#106), which adds the
README section this one links to; merge that first.