package-fatjars: keep only the target's own CPU natives in each all-backends jar

Each llama-<v>-all-<os>-<arch> fat jar was built as a copy of the default
fat jar plus the target's backend trees, so it carried the CPU natives of
all nine platforms: ~71.5 MB of 341.5 MB in all-windows-x86-64 (per-tree
sizes from run 36606543343). The introducing commit (aff68f5) gives no
reason for that; it was how the jar was assembled, and the README only
described it.

Every CPU tree except the jar's exact OS+arch is now removed before the
backends are added. That includes Windows/x86 and Windows/aarch64 in
all-windows-x86-64, so a 32-bit JVM on 64-bit Windows needs the default
fat jar, which is unchanged and still carries every platform.

Trees are the upper-case directories below net/ladenthin/llama/ (OSInfo
folder names; Java packages are lower-case), matched by exact path
component: a Linux* prefix would also hit Linux-Android, and a pattern
without the directory's trailing slash matches LlamaModel.class.

New fail-loud checks: the filter matched something; the own CPU library
is present and byte-identical to the default jar's; no other <OS>/<ARCH>
tree is left; the .class count equals the default jar's.

README: the all-backends jars no longer claim CPU natives for every
platform. CLAUDE.md: records the filter, the decision, and that the
"natives missing from a jar" incidents in the history (7ad8066,
40d564c) concern the default jar's collection, not this step.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AytmJF9faEiQEVt6eetQS2

Author: claude

.github/package-fatjars.sh

@@ -9,17 +9,25 @@
 #
 # For every OS/arch that has GPU classifier jars, the default jar-with-dependencies
 # uber jar (library classes + Java runtime deps + default CPU natives for every
-# platform) is copied and each backend's native tree is added under a backend
-# subdirectory (net/ladenthin/llama/<OS>/<ARCH>/<backend>/), together with a
-# jllama-backends.txt manifest listing the backends in priority order. LlamaLoader
-# reads that manifest at runtime and loads the first backend whose library loads,
-# falling back to the default CPU library (see LlamaLoader.BACKEND_MANIFEST_FILE).
+# platform) is copied, the CPU natives of every OTHER platform are removed, and each
+# backend's native tree is added under a backend subdirectory
+# (net/ladenthin/llama/<OS>/<ARCH>/<backend>/), together with a jllama-backends.txt
+# manifest listing the backends in priority order. LlamaLoader reads that manifest at
+# runtime and loads the first backend whose library loads, falling back to the
+# target's CPU library (see LlamaLoader.BACKEND_MANIFEST_FILE).
+#
+# The foreign CPU trees are dead weight in a jar named for one OS/arch (~71 MB of
+# 342 MB in all-windows-x86-64). Only the exact OS+arch of the jar name is kept, so
+# all-windows-x86-64 also loses Windows/x86 and Windows/aarch64: a 32-bit JVM finds
+# no natives there. The default fat jar (section 7) still carries every platform.
 #
 # Fail-loud invariants (a broken invariant must red the pipeline, never skip):
 #   * every <classifier> in llama/pom.xml must be parseable/explicitly excluded,
 #   * the pom classifier set and the on-disk classifier-jar set must match exactly,
 #   * every expected backend library must end up inside the combined jar,
-#   * the Main-Class of the combined jar must survive the zip update.
+#   * the Main-Class of the combined jar must survive the zip update,
+#   * a combined jar keeps its own CPU library (byte-identical), carries no other CPU
+#     tree, had at least one removed, and keeps every .class of the default fat jar.
 #
 # Usage: package-fatjars.sh <jars-dir> <out-dir> [pom]
 #   jars-dir  directory holding the `llama-jars` artifact (llama/target/*.jar)
@@ -62,6 +70,18 @@ is_excluded() {
     return 1
 }
 
+# Native CPU trees are the upper-case DIRECTORIES below net/ladenthin/llama/ (OSInfo
+# folder names: Linux, Linux-Android, Mac, Windows, ...); Java packages there are
+# lower-case. (Top-level class files such as LlamaModel.class are upper-case too, so
+# every match must require the trailing slash of a directory.) Prints <OS>/<ARCH>, sorted.
+native_trees() {
+    unzip -Z1 "$1" | sed -n -E 's#^net/ladenthin/llama/([A-Z][^/]*/[^/]+)/.*#\1#p' | sort -u
+}
+
+class_count() {
+    unzip -Z1 "$1" | grep -c '\.class$'
+}
+
 backend_priority_index() {
     local backend="$1" i
     for i in "${!BACKEND_PRIORITY[@]}"; do
@@ -194,6 +214,16 @@ for target in $(printf '%s\n' "${!TARGET_BACKENDS[@]}" | sort); do
 
     out_jar="$OUT_DIR/llama-$VERSION-all-$target-jar-with-dependencies.jar"
     cp "$BASE_FAT_JAR" "$out_jar"
+    # Drop every CPU tree but this target's (see the header). Matched by exact path
+    # components, never by prefix: a Linux* glob would also hit Linux-Android.
+    foreign_entries="$WORK_DIR/foreign-$target.txt"
+    unzip -Z1 "$out_jar" \
+        | awk -v keep="$resource_dir/" -v own_os="net/ladenthin/llama/$os_folder/" \
+            '/^net\/ladenthin\/llama\/[A-Z][^\/]*\// && index($0, keep) != 1 && $0 != own_os' \
+            > "$foreign_entries"
+    [ -s "$foreign_entries" ] \
+        || fail "$out_jar: no foreign CPU tree to remove — did the OSInfo folder names change?"
+    zip -q -d -nw "$out_jar" -@ < "$foreign_entries" || fail "$out_jar: removing foreign CPU trees failed"
     (cd "$staging" && zip -q -ur "$out_jar" net)
 
     # --- Verify the combined jar -----------------------------------------------------
@@ -206,6 +236,13 @@ for target in $(printf '%s\n' "${!TARGET_BACKENDS[@]}" | sort); do
         || fail "$out_jar: missing $resource_dir/jllama-backends.txt"
     unzip -p "$out_jar" META-INF/MANIFEST.MF | grep -qF "Main-Class: $MAIN_CLASS" \
         || fail "$out_jar: Main-Class $MAIN_CLASS did not survive the zip update"
+    unzip -p "$out_jar" "$resource_dir/$main_lib" | cmp -s - <(unzip -p "$BASE_FAT_JAR" "$resource_dir/$main_lib") \
+        || fail "$out_jar: CPU fallback $resource_dir/$main_lib is missing or differs from the default fat jar's"
+    out_trees="$(native_trees "$out_jar")"
+    [ "$out_trees" = "$os_folder/$arch_folder" ] \
+        || fail "$out_jar: expected only the CPU tree $os_folder/$arch_folder, found: $(echo "$out_trees" | tr '\n' ' ')"
+    [ "$(class_count "$out_jar")" -eq "$(class_count "$BASE_FAT_JAR")" ] \
+        || fail "$out_jar: .class count differs from the default fat jar — the CPU-tree filter removed classes"
     sample_backend="${ordered_backends[0]}"
     unzip -p "$out_jar" "$resource_dir/$sample_backend/$main_lib" \
         | cmp -s - "$staging/$resource_dir/$sample_backend/$main_lib" \

CLAUDE.md

@@ -470,12 +470,33 @@ Mechanism (three pieces):
    backends missing from its priority table, missing native trees, or zip-update corruption
    (entry list, `Main-Class`, sample byte-compare). Excluded by design: `msvc-windows`
    (redundant CPU variant) and `opencl-android-aarch64` (no `java -jar` on Android). For each
-   OS/arch it copies the default fat jar and adds every backend's native tree under
+   OS/arch it copies the default fat jar, **removes the CPU natives of every other platform**,
+   and adds every backend's native tree under
    `net/ladenthin/llama/<OS>/<ARCH>/<backend>/` plus a **`jllama-backends.txt`** manifest
    (backends in priority order `cuda13 rocm sycl-fp16 sycl-fp32 sycl vulkan opencl openvino`;
    extra tokens per line list sibling files such as openvino-windows' bundled `OpenCL.dll`).
    **A new classifier fails this script until it is consciously ranked/excluded** — that is the
    no-silent-gaps guarantee.
+
+   **Only the jar's own OS+arch CPU tree is kept.** Originally each combined jar was the
+   default fat jar plus backends, i.e. it carried the CPU natives of all nine platforms — ~71.5 MB
+   of dead weight in `all-windows-x86-64` (341.5 MB → ~270 MB, computed from the per-tree sizes of
+   run 36606543343). That was how the jar was built, not a requirement: the introducing commit
+   (`aff68f5e`) gives no reason, and the README merely described it. The rule is deliberately the
+   strict one, so `all-windows-x86-64` also loses `Windows/x86` and `Windows/aarch64` — a 32-bit JVM
+   on 64-bit Windows needs the default fat jar, which is untouched and still runs everywhere. The
+   own tree must survive: it is `LlamaLoader`'s fallback when no backend loads. The "natives missing
+   from a jar" incidents in the history are a different layer — the **default** jar's collection
+   (`package` once lacked `needs:` on three build jobs, `7ad8066a`; `merge-native-artifacts.sh`
+   guards the glob since `40d564c0`), which this filter sits downstream of.
+   Trees are found as the **upper-case directories** below `net/ladenthin/llama/` (OSInfo folder
+   names; Java packages are lower-case) and matched by exact path component — a `Linux*` prefix
+   would also hit `Linux-Android`, and a pattern without the trailing `/` of a directory matches
+   upper-case class files such as `LlamaModel.class`. Fail-loud checks: before the removal, that
+   the filter matched anything at all; after the zip update, that the own CPU library is present
+   and byte-identical to the default jar's, that **no other `<OS>/<ARCH>` tree is left**, and that
+   the `.class` count equals the default jar's (the check that caught the missing-slash variant
+   during development).
 2. **`LlamaLoader` backend selection** — when (and only when) the manifest resource exists,
    the loader tries each backend subdirectory in order: extract into a per-backend temp subdir
    (`jllama-backend-<name>/`; backends share file names), load manifest extras first, then the

README.md

@@ -281,12 +281,15 @@ java -jar llama-<version>-all-linux-x86-64-jar-with-dependencies.jar -m model.gg
 | `llama-<version>-jar-with-dependencies.jar` | none (CPU only, incl. macOS Metal) | — |
 
 Each all-backends jar contains the library classes, all Java runtime
-dependencies, the default CPU natives for **every** platform, and every GPU
-backend for its named OS/arch. At startup the loader tries the bundled backends
-in priority order (CUDA → ROCm → SYCL → Vulkan → OpenCL → OpenVINO) and uses
-the **first one whose native library loads**; if none loads — e.g. no GPU
-driver/toolkit installed — it falls back to the CPU natives, so the jar starts
-everywhere. The usual GPU policy applies: vendor runtimes are **not** bundled
+dependencies, the CPU natives for **its named OS/arch only**, and every GPU
+backend for that OS/arch — pick the jar that matches your platform. (A 32-bit
+JVM on 64-bit Windows, for example, needs the default
+`llama-<version>-jar-with-dependencies.jar` from the table above, which carries
+the CPU natives of every platform.) At startup the loader tries the bundled
+backends in priority order (CUDA → ROCm → SYCL → Vulkan → OpenCL → OpenVINO)
+and uses the **first one whose native library loads**; if none loads — e.g. no
+GPU driver/toolkit installed — it falls back to the CPU natives, so the jar
+starts on every host of its OS/arch, with or without a GPU. The usual GPU policy applies: vendor runtimes are **not** bundled
 (see the classifier table above for what each backend needs on the host).
 Force a specific backend with `-Dnet.ladenthin.llama.backend=<name>`
 (e.g. `vulkan`; fails loud instead of falling back) or force CPU with