release: 0.5.4 (sun.boot.class.path separator fix — niopatch.zip requ…

…ester / Trampoline Error)

On AmigaOS path.separator is ';' (':' is the volume separator), but
sun.boot.class.path was exposed as the VM's raw ':'-joined C boot path.
sun.misc.Launcher.getBootstrapClassPath() splits the property on path.separator,
so it read the whole value as ONE entry beginning "niopatch.zip:" -> AmigaDOS
popped a "Please insert volume niopatch.zip" requester and every
getBootstrapResource() returned null.  That broke sun.reflect.misc.MethodUtil:
it defined sun.reflect.misc.Trampoline via the bootstrap loader, so
Trampoline.<clinit> threw "Trampoline must not be defined by the bootstrap class
loader" (amigans.net post 161126; running SwingDemo / VmSuite).  HelloJava was
unaffected.

- vendor/jamvm (docs/jamvm-amiga-openjdk.patch, PATCH 13/13): amigaBootClassPathProperty()
  emits a SEPARATE ';'-joined ABSOLUTE Unix-form sun.boot.class.path anchored at
  java.home; the raw C bootpath stays ':'-joined for parseBootClassPath.
  classlibDefaultEndorsedDirs made Amiga-relative.
- tests/regression/BootClassPathTest.java (+ tools/build-tests.sh): asserts the
  property splits correctly, a bootstrap resource resolves, and a java.beans.Expression
  bounce through MethodUtil/Trampoline returns 5.  Fails pre-fix, passes on 0.5.4 and
  on a reference JVM.
- VERSION 0.5.4; README badge + note; CHANGELOG.md; CLAUDE.md status.

Verified on QEMU: SwingDemo opens with no requester; BootClassPathTest PASS on the
fixed VM and FAIL on the unfixed VM (reproducing the exact Error).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

release: 0.5.3 (Amiga-1251 charset NoClassDefFoundError fix)

Bumps VERSION + README badge to 0.5.3. The release runtime is 0.5.2 plus the
charset fix in libjava.so (src/openjdk/amiga_charset.h, called from
java_props_md.c ParseLocale): non-Latin AmigaOS locales that report a vendor
charset name like "Amiga-1251" no longer crash the VM at startup with
java.lang.NoClassDefFoundError "unsupported charset extension: Amiga-1251".

build/JavaOS4-0.5.3.lha (30817396 bytes); the bundled libjava.so carries the
fix. Validated on QEMU (JamVM/OpenJDK 8, ppc/clib4): CharsetLocaleTest 33/33,
ppc charset unit test 18/18, libjava.so boots clean (no regression).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

release: refresh jamvm Amiga patch to match the 0.5.2 binary

The vendor/jamvm `java -cp` + exit-path fixes (local commit c28250c) were not yet
reflected in docs/jamvm-amiga-openjdk.patch, which `make vendor` applies to rebuild
the VM from source.  Regenerated it (git format-patch 19465a4..HEAD) so a fresh
checkout of v0.5.2 rebuilds the released VM.  v0.5.2 tag re-pointed here.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs: link the GitHub Releases page for prebuilt .lha downloads

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Add an AmigaOS $VER: version cookie to the launcher + java script

`Version` reported no version info for the runtime.  Embed a $VER: cookie in
the jamvm-openjdk launcher (src/version/verstag.c, linked by
build-jamvm-openjdk.sh) and add a matching ;$VER: line to the generated `java`
script.

The version proper is the Java-OS4 project version as a clean major.minor
(0.5) -- AmigaOS `Version` rejects the cookie outright if the token after the
name is not parseable as major.minor, which is why the OpenJDK string
"1.8.0_492" failed on its own.  The OpenJDK class-library version follows as
free text, shown by `Version ... FULL`.  All values are stamped from the build
(VERSION file, the class-library JDK's release, build date).

Verified on target:
  Version jamvm-openjdk        -> "Java-OS4 0.5"
  Version jamvm-openjdk FULL   -> "Java-OS4 0.5 (11/06/2026)" / "OpenJDK 1.8.0_492"

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>