Skip to content

[#60] Build and validate an explicit JPMS module from Java 8 - #122

Open
peter-lawrey wants to merge 3 commits into
developfrom
feature/60-explicit-jpms-module
Open

peter-lawrey wants to merge 3 commits into
developfrom
feature/60-explicit-jpms-module

Conversation

@peter-lawrey

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

Copy link
Copy Markdown
Member

Build an explicit net.openhft.hashing descriptor on Java 8 and validate the retained JAR on later class paths and module paths. This retains the Stages 2 and 3 work from #60, including the #123 implementation. The hashing algorithms are unchanged by this increment.

The history now contains bmarwell's original signed #107 commit (cdbdc506) unchanged and one consolidated integration commit (b373003). The comparison base remains 4e721919a6eace335ce5921dfa4bde590ab1697f; the #123 implementation is retained. The existing Build/Sonar workflow is identical to #125 on develop, including its coverage handoff and late JaCoCo argument evaluation.

Review corrections:

  • Allow consecutive Maven lifecycles without clean by enabling ModiTect output replacement. CI repeats package after verification. The paired regression harness derives the JAR filename from project coordinates, so ordinary version bumps preserve the check.
  • Target ordinary consumers at Java 8 and modular consumers at Java 9, selected on 9+. Select HTML5 explicitly to prevent the independently reproduced JDK 10 Javadoc warning.
  • Inherit user Maven settings while keeping the isolated consumer repository. Document the complete ./mvnw verify lifecycle.
  • Require the final multi-release manifest marker generated by ModiTect. Remove the redundant explicit JAR/bundle marker settings and their unsupported test claims. Declare optional requires static jsr305, and check descriptor semantics and annotation resolution with jdeps.
  • Build once on Java 8, retain the binary and provenance, and execute that exact binary on JDK 8/9/10/11/17/21/25. Every job compares its installed JAR with the retained checksum and uploads its reports.

Use ModiTect 1.2.2 because 1.3 declares a Java 11 prerequisite. The new workflow uses the checked-in Maven 3.9.11 wrapper consistently. The existing project-wide version gate is preserved; TeamCity's Maven 3.8.2 was also verified directly.

Validation:

  • Current-tree Java 8 verify/package pairs pass at the project version and a private 2026.2-SNAPSHOT version bump. Each verify arm reports 14,905 unit cases with 12 retained skips, three packaged-JAR tests and five classpath cases, with zero failures/errors. All 62 library class files match the retained CI binary at the current coordinates; at the bumped version, the descriptor differs only by its version string. Negative controls reproduce the hardcoded-path failure, missing-overwrite failure, unflipped-negative guard and final-manifest/descriptor assertions.
  • Retained previous-head local verification passed on JDK 8, 9, 10, 11 and 21. Java 8 reports 14,905 unit cases with 12 skips; later JDKs run both string configurations, each reporting 14,905 cases with 5/8 skips. Three packaged-JAR checks and the applicable consumer fixtures pass. Java 21 coverage thresholds pass.
  • Retained previous-head controls: repeat packaging passed with Maven 3.8.2 and 3.9.16. Removing the manifest marker fails the intended assertion. A cold-repository mirror-only dependency test passes with inherited settings and fails when the old override is restored.
  • Retained CI on previous head 76ce46f: the Build job passes. The artifact workflow passes all seven consumer jobs: 59 cases, zero failures/errors/skips among executed cases. Java 8 deliberately skips the modular fixture. JDK 10 required one retry after Invoker failed to load before testing; that failed attempt is retained separately.
  • The retained CI Java 8 binary has SHA-256 63087921e407c7d98d3673ddd9cd4827b5806796eac7d5e6fd432b5b1fda1cec. Its synthetic checkout matches the previous 76ce46f PR tree. Current-tree Java 8 builds preserve its 62 class-file bytes; the recorded whole-JAR hash and multi-JDK CI results retain their original subject identities.

Open and non-draft; the revised source awaits fresh review and CI results. Previous-head qualification recorded eight successful TeamCity jobs, with Windows and macOS pending. The previous-head Sonar job rejected the configured credential, leaving administrator repair outstanding. Its optional quality profile reported the same 7,844 Checkstyle violations as the merged baseline and stopped before SpotBugs.

Refs #60, #107, #119, #123, #125.

Copy link
Copy Markdown
Member Author

@bmarwell GitHub cannot add you as a formal requested reviewer because it reports that review requests are limited to repository collaborators, but your review is warmly invited. This continuation retains your original commit and the full #107 head unchanged in its ancestry.

@bmarwell

Copy link
Copy Markdown

It is totally fine as a start

@tgd
tgd removed request for james-mcsherry and tgd August 26, 2026 18:08
Base automatically changed from feat/Zero-Allocation-Hashing-60-review-pr-107-for-compatibility-ci to develop September 9, 2026 15:02
@peter-lawrey
peter-lawrey marked this pull request as ready for review September 11, 2026 18:34
@peter-lawrey peter-lawrey changed the title [#60] Add a deterministic explicit JPMS descriptor [#60] Build and validate an explicit JPMS module from Java 8 Sep 17, 2026
Preserve Benjamin Marwell's original signed #107 commit as a parent,
and consolidate Peter Lawrey's #122/#123 integration and the local
review corrections against the existing comparison base.

Remove redundant manifest settings: source-removal controls retain
the final multi-release flag and all library class bytes. Derive the
repeat-package harness JAR name from project coordinates so normal
version bumps retain the paired overwrite regression.

Keep the Java 8 classes, Java 9 descriptor, public API, pinned inputs
and contributor fixtures. Original commits and exact mappings are
retained in the operator receipt and archive-reviewed-r0003 branch.

Co-authored-by: Peter Lawrey <peter.lawrey@chronicle.software>
@peter-lawrey
peter-lawrey force-pushed the feature/60-explicit-jpms-module branch from 76ce46f to b373003 Compare October 4, 2026 22:38
@peter-lawrey
peter-lawrey requested a review from a team as a code owner October 4, 2026 22:38
@sonarqubecloud

sonarqubecloud Bot commented Oct 9, 2026

Copy link
Copy Markdown

This branch has not been deployed

No deployments
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.

2 participants