Skip to content

[#60] Complete JPMS runtime compatibility through Java 25 - #123

Draft
peter-lawrey wants to merge 2 commits into
feature/60-explicit-jpms-modulefrom
feature/60-module-path-hardening
Draft

[#60] Complete JPMS runtime compatibility through Java 25#123
peter-lawrey wants to merge 2 commits into
feature/60-explicit-jpms-modulefrom
feature/60-module-path-hardening

Conversation

@peter-lawrey

@peter-lawrey peter-lawrey commented Aug 21, 2026

Copy link
Copy Markdown
Member

Summary

Final hardening stage for #60, stacked on #122 (which is stacked on #119).

This PR validates the explicit net.openhft.hashing module through Java 25 while preserving the established direct-buffer fast path:

  • exercises every public LongHashFunction factory, LongTupleHashFunction.xx128(), arrays, heap and direct ByteBuffer, String, StringBuilder, and primitive arrays from a named consumer;
  • keeps the performance-sensitive direct sun.nio.ch.DirectBuffer.address() invocation; it does not introduce reflection or a reflective fallback;
  • tests and documents the required Java 9+ export for named-module and class-path consumers;
  • verifies that the compile-time DirectBuffer stub is not shipped;
  • expands direct-buffer correctness coverage for offsets, byte order, and unchanged position/limit;
  • documents the Java 24/25 Unsafe warning and the small application-side suppression option, while leaving a performance-sensitive VarHandle/FFM migration to separate work.

The consumer follows the repository convention: module net.openhft.it.module contains package net.openhft.it.module.

Runtime requirements

Direct-buffer hashing deliberately requires:

Named module: --add-exports java.base/sun.nio.ch=net.openhft.hashing
Class path:   --add-exports java.base/sun.nio.ch=ALL-UNNAMED

Without the relevant export, Java 25 raises IllegalAccessError; that expected failure was reproduced for both deployment forms. There is no fallback to reflection.

Java 25 also warns once per JVM when the library first invokes a terminally deprecated sun.misc.Unsafe memory-access method. --sun-misc-unsafe-memory-access=allow suppresses that warning for applications which explicitly accept the temporary compatibility risk. Eliminating the dependency properly is not a small JPMS change and is outside this PR.

Validation

Canonical artefact: the JAR produced by the Java 8 clean build was copied unchanged to /tmp/zah60-stage3-jdk8.jar.

SHA-256: a468b81e3956b6da43376a6620e83a791bedddfb57cfb6250410958ece50361e
  • Java 8 mvn -B clean verify: passed; 14,901 tests, 12 skips; packaged-JAR tests and class-path consumer passed.
  • Exact Java 8-built JAR on the class path: passed on Java 8, 11, 17, 21, and 25, including every public hash factory and direct ByteBuffer.
  • Exact Java 8-built JAR on the module path: passed on Java 11, 17, 21, and 25 as explicit named, non-automatic module net.openhft.hashing, including every public hash factory and direct ByteBuffer.
  • Every runtime in both matrices produced the same aggregate hash checksum: 8409002548710940386.
  • Java 25 mvn -B clean verify: passed; both 14,901-test executions, packaged-JAR tests, class-path consumer, and named-module consumer passed.
  • The Java 25-built JAR retained Java 8 class-file version 52 and passed the same direct-buffer smoke test on both Java 8 and Java 25.
  • Java 25 jlink image built from the exact Java 8-built JAR: passed and included net.openhft.hashing plus jdk.unsupported.
  • jar --validate: passed.
  • jar --describe-module --release 9: exports only net.openhft.hashing; requires jdk.unsupported.
  • Archive inspection: META-INF/versions/9/module-info.class present; sun/nio/ch/DirectBuffer.class absent.
  • jdeps --multi-release 25 --jdk-internals: confirms the known sun.misc.Unsafe and sun.nio.ch.DirectBuffer dependencies; both are documented.
  • Java 25 Unsafe modes checked: default warn passes, allow passes without the warning, debug identifies all call sites, and deny fails at UnsafeAccess initialisation as expected.
  • git diff --check: passed.

The legacy Sonar workflow failure occurs before checkout because it still uses a retired action. Workflow/Sonar maintenance is deliberately a separate concern and this PR does not modify it.

Stack and merge order

  1. [#60] Publish a stable JPMS automatic module name #119 — stable automatic module name
  2. [#60] Add a deterministic explicit JPMS descriptor #122 — deterministic explicit descriptor, preserving [#60] Add JPMS module descriptor, add Maven IT #107's original commits and attribution
  3. this PR — runtime hardening and documented Java 25 support

After #119 and #122 merge, this PR should be rebased or retargeted to develop without changing the packaging mechanism established by #122.

Fixes #60

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant