# Java SDK native source packaging from the complete harness archive

2026-10-03. Source generation `018fa6c2371bd9f3c3dbedabfc8a271cc3ad1511`,
retained separately from its integration commit. This closes the Java native
source producer's development-layout dependency. It does not qualify a
standalone release or a Stage 5 campaign.

## Change

`prepare_libhft_xmachine_bundle.py` now accepts independently supplied Java
and C++ SDK source roots through `--java-source` / `LIBHFT_JAVA_SOURCE` and
`--cpp-source` / `LIBHFT_CPP_SOURCE`. CLI inputs win; missing explicit sources
fail before output replacement. Development defaults keep their original
engine paths. The flat harness defaults to the sibling Java SDK and its
versioned `native/cpp` subtree. Framework inputs always belong to the harness.

Native-only preparation works without Git or prebuilt artifacts. It retains
copied-file hashes, owning source identities and supplied licence/notice files;
it creates no benchmark bundle. An archive cannot borrow its enclosing Git
identity. Full bundle creation keeps that refusal; an unqualified/dirty SDK
requires the diagnostic flag and marks the bundle dirty. Skipped freshness
also marks a full bundle diagnostic. Explicit SDK/framework JAR inputs retain
the freshness checks and hashes in the bundle manifest.

The staged compiler fragment is portable and preserves caller compiler
selection and owning SDK flags. Development still stages its existing policy.
The generated native builder requires an absolute separate build root and
caps parallelism at sixteen (default two). It queries the actual SDK Makefile
output rather than assuming that open and pro libraries share one suffix.
Clean and build operations are sequential. Runtime libraries are then copied
to the declared bundle using the existing packaging locations.

The original producer and preparation assertions remain under
`internal/bench/java/fixbench/scripts/native-sdk-inputs-before-20261003/`.
All five existing preparation cases remain; the remote-script assertion now
checks separate clean/build commands and the same SSL input.
Shared layout, clock and build helper APIs, Stage 2 contracts, wire fixtures,
installed payloads and report admission logic are unchanged.

## Actual archive checks on HP

The full benchmark manifest plus templates supplies **751 files**, with exact
Git modes. The independently supplied Java SDK manifest plus templates supplies
**826 files**, including the matching C++ headers/kernels and open Java/native
sources. These are raw source selections for a functional check, not an
admitted/released public export. Both lack Git and sit inside an unrelated
Git/development tree whose engine Makefile and toolchain deliberately fail.

The outermost foreground command uses the high-priority **shared** host slot.
Status, running compiler/JVM processes and memory are retained before each
generation. This is functional scope; unrelated processes are visible in the
continuation preflight and there is no exclusive or timing grade.

Results retained across the immutable generations:

- Ten preparation tests and six provenance tests pass, zero skips. The five
  original preparation cases are included. Local checks pass the same sixteen.
- Actual archive CLI native-only staging passes with SDK paths containing
  spaces. All harness/SDK identities remain unqualified; copied source hashes
  and supplied Java `LICENSE`/`NOTICE` bytes are checked.
- Full bundle creation refuses the enclosing Git identity even with
  `--allow-dirty`; an explicit missing SDK refuses. Neither creates outputs.
- The generated builder freshly compiles both affinity JNI and engine open
  JNI with GCC 14, two jobs, and the owning O3/C++11 flags. Engine JNI uses
  `WITH_SSL=0`; this is no TLS/provider qualification. The actual queried output
  is `engine/java/target/native-open/libhftjava.so`, copied byte-identically
  into both declared bundle locations. All staged native sources stay unchanged.
- Maven freshly builds a matching open SDK JAR. Engine unit suites are
  deliberately omitted; the native build is already supplied by the actual
  generated builder. These omissions are not counted as passing unit tests.
- Two real engine JVM loads pass: exact library and published build-root
  discovery. `NativeEngine.open()` verifies the matching SDK/native ABI and
  queries its version. A third JVM loads affinity JNI, queries a leased CPU
  and exercises the invalid-bind result.
- An explicit missing native library refuses despite a valid fallback input.
  A separately retained older SDK JAR refuses against the fresh JNI library
  with an actual ABI error. That older read-only artifact remains unchanged.
- All 751 harness and 826 SDK files retain their bytes and modes; there are
  no source outputs. The source/capsule materializations are removed after
  checking. The original refused build-root materialization is independently
  checked before removal.

## Original failures and continuation

The first full generation correctly refuses the controller's parent build
root, which contained its staged source directory. Its original failed receipt
and logs are retained. A new complete generation uses sibling source/build
directories, passes both native builds and the fresh JAR build, then fails the
outer probe compiler because the controller omitted the framework source path.
No production source correction was required for either failure.

A separate **read-only continuation** supplies that source path and performs
the real loads and negative controls against the already built, byte-checked
JAR/native pair. It does not rewrite either failed generation or infer a
passing build from the probe. Small receipts, source maps, commands and logs:
[evidence/java-sdk-sources-20261003](evidence/java-sdk-sources-20261003/).
All three durable generations, source tarballs and the final runtime artifacts
remain under `~/archive/libhft/java-sdk-sources-20261003-018fa6c2371b*`.
SDK source tarballs and runtime binaries stay outside the repo/website evidence.

Readiness at the qualified source selects 748 files with zero scrub findings,
private/unresolved references or dead documentation links, and 83 textual
root escapes. A clean scan does not establish whole-harness closure.

## Remaining gates

This qualifies the exact recorded native source producer, generated builder
and matching supplied SDK generation. Concurrent engine changes do not acquire
that matching artifact proof; the integrated input map records any changes.
The full engine unit suite, pro JNI build, TLS/providers, Java full-session
fixture/physical/rate/stability gates, other language SDK paths, whole-harness
source/licence review and public release process remain open.

## Concurrent integration

The original generation remains pinned. Of its 751 harness inputs, 748 remain
unchanged after rebase: the public guide gains the sibling-build example, and
the other session's matrix runner/test now supply the renderer's explicit data
and output roots. Those changes are preserved and the focused matrix tests pass.
Every qualified Java producer/runtime/shared native helper input stays unchanged.

Of the recorded 826 SDK inputs, 817 remain unchanged. Engine owners repaired
public file-store snapshot admission and replay buffer lifetime, initiator
replay, edition test placement, shared codec vectors and public JNI instructions.
Their nine changed inputs are retained with both hashes in
`readonly-loads/integration-inputs.json`; additional selected native test units
belong to their qualification. The fresh matching JAR/native proof here stays
with its original SDK source pin. It does not certify rebuilt artifacts for the
new engine sources. No original source map, failed log or raw result is rewritten.