Update SMIMETest.java

.claude/skills/build-jdk13-docker/Dockerfile

@@ -0,0 +1,28 @@
+# Runtime environment for the bc-java jdk1.3 (build1-3) legacy build.
+#
+# Base: Debian 4.0 "etch" i386 (glibc 2.3.6). Chosen deliberately:
+#   * i386 userland  -> matches the 32-bit Sun JDK 1.3.1 binaries.
+#   * glibc < 2.4    -> no PTR_MANGLE pointer mangling. Sun's Classic VM green
+#                       threads hand-roll jmp_buf context switches; on glibc
+#                       >= 2.4 (e.g. bullseye/jessie 2.19) longjmp demangles a
+#                       raw poked-in PC and jumps to garbage -> SIGSEGV. 2.3.6
+#                       does not mangle, so the Classic/green VM runs.
+# The host kernel is shared (containers share it), but green threads are
+# user-space, so no kernel-version dependency bites here.
+FROM debian/eol:etch
+
+# The 2001-era Sun launch wrapper (bin/.java_wrapper) predates x86-64: it reads
+# `uname -m`, and because this container shares the host's amd64 kernel that
+# returns "x86_64", which the wrapper cannot map to its i386 lib dir -> it dies
+# with "can't find libjava.so". apt is dead on EOL etch (no `linux32`), so shim
+# `uname -m` to report i686. Everything else passes through to the real uname.
+RUN cp -a /bin/uname /bin/uname.real \
+ && printf '%s\n' \
+      '#!/bin/sh' \
+      'if [ "$1" = "-m" ]; then echo i686; exit 0; fi' \
+      'exec /bin/uname.real "$@"' > /bin/uname \
+ && chmod 0755 /bin/uname
+
+# Nothing else is baked in: the JDK, ant, aux jars and the repo are all
+# bind-mounted at run time by build-jdk13.sh so the image stays tiny and the
+# host tree is the single source of truth.

.claude/skills/build-jdk13-docker/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: build-jdk13-docker
+description: Build and test the legacy jdk1.3 (build1-3) distribution on a modern host by running the genuine Sun JDK 1.3.1 inside an i386 / glibc-2.3.6 Docker container. Use this whenever the user wants to run "build1-3" / the "jdk1.3" or "Java 1.3" build, get a bcprov-jdk13 jar, reproduce a genuine-1.3 compile failure, or when a genuine JDK 1.3.1 won't start on the host ("can't find libjava.so", missing libstdc++-libc6.1-1.so.2, or a green-threads Classic VM segfault). Captures the container recipe, why glibc < 2.4 is mandatory, the uname/libstdc++/threads traps, and that the jdk1.3 source overlays have rotted (the real source floor is Java 1.4).
+---
+
+# Building and testing the jdk1.3 (build1-3) distribution in Docker
+
+The `jdk1.3` distribution is driven by `sh build1-3` → `ant/jdk13.xml` → `ant/bc+-build.xml`,
+compiling with the **real Sun JDK 1.3.1** at `/opt/jdk1.3.1` and running tests on the same JRE.
+Like `build1-4` it is a genuine-1.3 *compile* floor (post-1.3 APIs fail at compile time), but it
+adds two things the jdk1.4 build does not: it builds its own **clean-room JCE** first (from
+`jce/src/`, so **no jar signing** is needed — unlike jdk1.4/jdk15to18), and its preprocessor
+rewrites the Java-1.4 cert-path API (`java.security.cert.CertStore/CertPath/PKIX*/…Selector`) to
+BC's `org.bouncycastle.jce.cert.*` backport, plus `LinkedHashSet`→`HashSet`.
+
+The blocker this skill solves: **a 2001-era 32-bit Sun JDK 1.3.1 cannot run on a modern Linux
+host.** The fix is to run it in a period-appropriate i386 container.
+
+## Quick start
+
+```
+.claude/skills/build-jdk13-docker/build-jdk13.sh provider   # build the provider -> bcprov-jdk13 jar
+.claude/skills/build-jdk13-docker/build-jdk13.sh test        # full build + tests
+.claude/skills/build-jdk13-docker/build-jdk13.sh shell       # interactive 1.3 container (fast iteration)
+.claude/skills/build-jdk13-docker/build-jdk13.sh             # full build (no arg)
+```
+
+First run builds a tiny image (`bc-jdk13:etch`). i386 executes natively on an x86-64 kernel — **no
+qemu**. Everything (JDK, ant, aux jars, the repo) is bind-mounted from the host; only a `uname`
+shim is baked into the image. A full `provider` round is ~10 min (the `<replaceregexp>` preprocess
+over ~6,800 files dominates, then the nojit Classic VM compiles).
+
+## Why a genuine JDK 1.3.1 won't run on the host — and why etch
+
+`/opt/jdk1.3.1` (→ `/opt/installs/jdk1.3.1_20`) is a 32-bit x86 Sun JDK. On Ubuntu 24.04:
+
+1. **`uname` wall (cosmetic).** Its launch wrapper (`bin/.java_wrapper`) predates x86-64: it reads
+   `uname -m`, gets `x86_64` (the container shares the host's amd64 kernel), can't map that to its
+   i386 lib dir, and dies with **"can't find libjava.so."** Fixed by the image's `uname -m`→`i686`
+   shim (apt is dead on EOL etch, so there is no `linux32`).
+2. **VM wall (fatal on the host).** After that:
+   - the default `-client`/HotSpot VM uses **native threads** whose launcher binary links the
+     extinct **`libstdc++-libc6.1-1.so.2`** (gone from modern distros; and 1.3 native threads on
+     NPTL is broken anyway);
+   - the `-classic` VM uses **green threads** and needs no libstdc++ — but it **segfaults** on
+     glibc ≥ 2.4. Cause: glibc 2.4 added `PTR_MANGLE` pointer mangling; Sun's green threads
+     hand-roll `jmp_buf` context switches, so `longjmp` demangles a raw poked-in PC and jumps to
+     garbage (`catchsegv` shows `EIP == fault address`, empty backtrace).
+
+So the container base must be **i386 with glibc < 2.4**. `debian/eol:etch` (Debian 4.0, **glibc
+2.3.6**) works; `debian/eol:sarge` (2.3.2) also works; anything ≥ 2.4 (jessie 2.19, …) segfaults.
+Green threads are user-space, so the shared modern host **kernel** is not a problem.
+
+The recipe therefore forces the **Classic VM / green threads** via a custom `jvm.cfg` (`-classic`
+first = default VM → wrapper selects green threads → no libstdc++), sidestepping both VM problems.
+
+## Recipe internals (in this skill dir)
+
+- **`Dockerfile`** — `FROM debian/eol:etch`; the only customization is the `uname -m`→`i686` shim.
+- **`jvm.cfg`** — reorders `-classic` to the top so every forked `java`/`javac` defaults to the
+  green-threads Classic VM. Mounted over `/opt/jdk1.3.1/jre/lib/jvm.cfg` (works because that file
+  already exists in the ro JDK mount).
+- **`build-jdk13.sh`** — bind-mounts the JDK at `/opt/jdk1.3.1` (matching `build1-3`'s hardcoded
+  `JDKPATH`), ant `/opt/apache-ant-1.6.5`, `/opt/javamail-1.3.1`, `/opt/jaf-1.0.2`, and the repo at
+  `/work`; exports the `JAVA_MAIL_HOME`/`JAVA_ACTIVATION_HOME` that `build1-3` uses but forgets to
+  set; runs as your uid so build artifacts aren't root-owned.
+
+Two non-obvious mount facts:
+- **ORO for `<replaceregexp>`.** JDK 1.3 has no `java.util.regex`, so ant's regexp preprocessing
+  needs a Jakarta ORO impl (`/opt/ant/lib` ships only the `ant-apache-oro` *adapter*). The script
+  locates an `oro-2.0.x.jar` (default `~/.m2/.../oro/2.0.8`) and injects it with `ANT_ARGS="-lib
+  /opt/extralib"`. It is **not** dropped into `/opt/ant/lib` because docker cannot create a new
+  mountpoint file inside the read-only `/opt/ant` mount (that fails with "read-only file system").
+- `--platform linux/386` sets the userland arch but **not** the syscall personality, so `uname -m`
+  still returns `x86_64` — hence the image `uname` shim rather than relying on `linux32`.
+
+## The jdk1.3 overlays have rotted — the real source floor is Java 1.4
+
+`build1-3 provider` does not currently produce a jar out of the box: the current `src/main/java`
+uses **Java 1.4 APIs** that the jdk1.3 tree never caught up with. Known breakages (fixed where
+noted; expect more to surface as each layer clears):
+
+- **`Throwable.initCause` (Java 1.4, absent in 1.3).** Everything routes through
+  `org.bouncycastle.util.Exceptions` and `org.bouncycastle.jcajce.provider.util.SecurityExceptions`,
+  whose base classes chain via `initCause`. Handled with **jdk1.3 overlays** that construct
+  message-only (1.3 has no `getCause`, so no caller can observe a dropped cause) — keep the message
+  text verbatim (test contract) and the factory signatures in lockstep with base. Direct
+  `initCause`/`getCause` users outside those two factories need per-file overlays too (grep them:
+  `grep -rl '\.initCause(\|\.getCause(' core/src/main/java prov/src/main/java`).
+- **`@Deprecated` survived preprocessing** (`illegal character: \64` = `@`, then cascading
+  `<identifier> expected`). Root cause: the shared `ant/build.regexp` `${regexp}` strips
+  `@Override`/`@SuppressWarnings`/`@FunctionalInterface` but **not** `@Deprecated`; `jdk14.xml` has
+  a dedicated `@Deprecated` pass and `jdk13.xml` was missing it. **Fixed** by mirroring that pass
+  into `ant/jdk13.xml`. (If a new annotation type appears, add a pass the same way.)
+
+The Java-1.4-vs-1.3 delta is narrow in reachable code (`initCause`/`getCause` a handful of files,
+plus a few `java.net.URI`/`java.nio.*` users, most of which already have overlays). There are **no**
+`assert` statements or `java.util.regex` uses in reachable main code. So the effort is overlay-sync,
+not a rewrite. Follow the overlay discipline in `docs/claude/build-jdk14.md` (prefer deleting an
+overlay when base is 1.3-clean after preprocessing; NOTE-comment every overlay that must exist;
+keep `core/src/main/jdk1.3/.../util/Properties.java` mirroring base constants).
+
+## Iterating fast
+
+The `<replaceregexp>` preprocess is the ~7-min bottleneck, and the staging tree is **never cleaned**
+by the build (stale sources keep compiling), so after changing overlays/excludes:
+
+```
+rm -rf build                                         # on the host; build/ is gitignored
+.claude/skills/build-jdk13-docker/build-jdk13.sh provider
+```
+
+For tighter loops use `shell`: it drops you into the 1.3 container with everything mounted, so you
+can run `sh build1-3 provider` (or `ant -f ant/jdk13.xml build-provider`) directly and re-run after
+editing overlays in `/work`, without paying container startup each time. Errors go to the console;
+failed test suites write per-suite XML under `build/artifacts/jdk1.3/reports/xml/`.
+
+Verify overlay fixes against the real build — the preprocessor plus 1.3 javac is the only authority,
+never eyeball. Related: `docs/claude/build-jdk14.md`, the `build-jdk15to18` skill, and CLAUDE.md's
+"Main source stays Java 4 compatible" note (the maintained floor is 1.4; 1.3 is stricter still).

.claude/skills/build-jdk13-docker/build-jdk13.sh

@@ -0,0 +1,89 @@
+#!/bin/sh -
+#
+# Drive the bc-java jdk1.3 (build1-3) legacy build inside an i386 / glibc-2.3.6
+# container, because a genuine Sun JDK 1.3.1 no longer runs on a modern host
+# (its native-threads launcher needs the extinct libstdc++-libc6.1-1.so.2, and
+# its green-threads Classic VM segfaults on glibc >= 2.4 pointer mangling).
+#
+# Usage:
+#   ./build-jdk13.sh                # full build   (build1-3, no arg)
+#   ./build-jdk13.sh provider       # provider only (build1-3 provider)
+#   ./build-jdk13.sh test           # build + run the test suite
+#   ./build-jdk13.sh shell          # interactive shell in the container (debug)
+#
+# Override any host path via env, e.g.  BC_JAVA=/path/to/bc-java ./build-jdk13.sh
+#
+set -e
+
+SCRIPT_DIR=$(cd "$(dirname "$0")" && pwd)
+
+# --- host paths (all bind-mounted read-only except the repo) -----------------
+BC_JAVA=${BC_JAVA:-/home/dgh/bc/git/repositories/bc-java}
+# Resolve the /opt/jdk1.3.1 symlink to its real target so the mount is stable.
+JDK_HOST=${JDK_HOST:-$(readlink -f /opt/jdk1.3.1)}
+ANT_HOST=${ANT_HOST:-/opt/apache-ant-1.6.5}
+MAIL_HOST=${MAIL_HOST:-/opt/javamail-1.3.1}
+JAF_HOST=${JAF_HOST:-/opt/jaf-1.0.2}
+IMAGE=${IMAGE:-bc-jdk13:etch}
+
+# ORO impl for ant's <replaceregexp> (JDK 1.3 has no java.util.regex). Not
+# bundled with the skill (it is a binary); located from common host spots, or
+# set ORO_JAR explicitly. Any jakarta-oro / oro 2.0.x jar works.
+if [ -z "$ORO_JAR" ]; then
+    for c in /home/dgh/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar \
+             /home/dgh/.m2/repository/oro/oro/2.0.7/oro-2.0.7.jar \
+             "$SCRIPT_DIR"/oro-*.jar "$SCRIPT_DIR"/jakarta-oro*.jar; do
+        [ -e "$c" ] && { ORO_JAR=$c; break; }
+    done
+fi
+
+for p in "$BC_JAVA/build1-3" "$JDK_HOST/bin/.java_wrapper" "$ANT_HOST/bin/ant" \
+         "$MAIL_HOST/mail.jar" "$JAF_HOST/activation.jar" "$ORO_JAR" \
+         "$SCRIPT_DIR/Dockerfile" "$SCRIPT_DIR/jvm.cfg"; do
+    [ -n "$p" ] && [ -e "$p" ] || {
+        echo "ERROR: missing required path: ${p:-<ORO_JAR unset: set ORO_JAR=/path/to/oro-2.0.x.jar>}" >&2
+        exit 1
+    }
+done
+
+# --- build the (tiny) image once ---------------------------------------------
+if ! docker image inspect "$IMAGE" >/dev/null 2>&1; then
+    echo ">> building $IMAGE"
+    docker build --platform linux/386 -t "$IMAGE" "$SCRIPT_DIR"
+fi
+
+# --- what to run inside -------------------------------------------------------
+if [ "$1" = "shell" ]; then
+    RUNCMD="exec /bin/sh"
+    TTY="-it"
+else
+    # build1-3 references $JAVA_MAIL_HOME / $JAVA_ACTIVATION_HOME but never sets
+    # them, and hardcodes JDKPATH=/opt/jdk1.3.1 -- so we mount the JDK there and
+    # export the two homes. ANT_HOME is auto-detected by the ant script.
+    RUNCMD="cd /work && exec sh build1-3 $*"
+    TTY=""
+fi
+
+# --- run ----------------------------------------------------------------------
+# Nested bind mounts overlay a single file inside a read-only tree:
+#   * jvm.cfg -> make -classic (green threads) the default VM. This works only
+#     because jvm.cfg already EXISTS in the ro JDK mount; docker cannot create a
+#     NEW mountpoint inside a ro mount (that is why oro goes to its own dir and
+#     is added with ant -lib, not dropped into the ro /opt/ant/lib).
+exec docker run --rm $TTY --platform linux/386 \
+    --user "$(id -u):$(id -g)" \
+    -e HOME=/tmp \
+    -e JAVA_MAIL_HOME=/opt/javamail-1.3.1 \
+    -e JAVA_ACTIVATION_HOME=/opt/jaf-1.0.2 \
+    -e ANT_HOME=/opt/ant \
+    -e ANT_ARGS="-lib /opt/extralib" \
+    -e PATH=/opt/jdk1.3.1/bin:/opt/ant/bin:/usr/bin:/bin \
+    -w /work \
+    -v "$BC_JAVA":/work \
+    -v "$JDK_HOST":/opt/jdk1.3.1:ro \
+    -v "$SCRIPT_DIR/jvm.cfg":/opt/jdk1.3.1/jre/lib/jvm.cfg:ro \
+    -v "$ANT_HOST":/opt/ant:ro \
+    -v "$ORO_JAR":/opt/extralib/oro.jar:ro \
+    -v "$MAIL_HOST":/opt/javamail-1.3.1:ro \
+    -v "$JAF_HOST":/opt/jaf-1.0.2:ro \
+    "$IMAGE" /bin/sh -c "$RUNCMD"

.claude/skills/build-jdk13-docker/jvm.cfg

@@ -0,0 +1,17 @@
+#
+# Reordered jvm.cfg for the bc-java jdk1.3 Docker build.
+#
+# First non-# line is the DEFAULT VM. We put -classic first so that every
+# `java`/`javac` the build forks selects the Classic VM, which the launch
+# wrapper runs with GREEN THREADS. That matters twice:
+#   * the green-threads launcher binary does NOT link the extinct
+#     libstdc++-libc6.1-1.so.2 that the native-threads (client/hotspot)
+#     launcher needs (and which no modern distro ships);
+#   * green threads are user-space, sidestepping the LinuxThreads-vs-NPTL
+#     mismatch that breaks Sun 1.3 native threads.
+# The other VMs stay listed so an explicit -client/-server still resolves.
+#
+-classic
+-client
+-hotspot
+-server