Issue 148 forward fixes JDK 25 build stage distroless WORKDIR and jdt2jar helper - #151
Conversation
…ck for macOS/Colima
…, clean up README
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9b093ed6e7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| mkdir -p "$WORK_DIR" | ||
|
|
||
| # Sync source (respecting .gitignore) | ||
| rsync -a --filter=':- .gitignore' --exclude='.git/' . "$WORK_DIR/" |
There was a problem hiding this comment.
When the requested schema is under any ignored path, this filter omits it from the staging directory while line 22 passes the original path unchanged to the container, so compilation fails with Schema file not found. This affects the script's own .tmp/test.jtd.json example because the repository .gitignore excludes .tmp; as rsync --help describes, --filter adds file-filtering rules, so the explicitly requested schema must be copied regardless of ignore rules.
Useful? React with 👍 / 👎.
| docker run --rm -v "$WORK_DIR:/work" "$IMAGE" "$@" | ||
|
|
||
| # Sync output back (any new .jar or .java files in the work dir) | ||
| rsync -a --include='*.jar' --include='*.java' --exclude='*' "$WORK_DIR/" ./ |
There was a problem hiding this comment.
When --output names a nested path such as the script's own .tmp/test.jar example, this filter does not copy the generated JAR or companion source back. rsync --help describes --include as preventing matching files from being excluded, but the parent .tmp/ directory still matches the final --exclude='*', so rsync never descends to the included files; directory traversal must also be included.
Useful? React with 👍 / 👎.
| - **Interpreter** ([`json-java21-jtd`](../json-java21-jtd/README.md)): ideal for infrequent config parsing — simple, no build step, runs on JDK 21+. | ||
| - **Codegen** ([`json-java21-jtd-codegen`](../json-java21-jtd-codegen/README.md)): ideal for repeated hot-path validation — ~9x faster, but requires JDK 24+ at runtime. | ||
| - **jdt2jar**: pre-compiles schemas into validator JARs at build time (using JDK 24+), then deploys them to any JDK 21+ runtime. Best for CI/CD pipelines, distroless containers, or environments where you want JIT-optimised validators without shipping a JDK 24+ runtime. | ||
| - **Codegen** ([`json-java21-jtd-codegen`](../json-java21-jtd-codegen/README.md)): ideal for repeated hot-path validation — ~9x faster, but requires JDK 25+ at runtime. |
There was a problem hiding this comment.
This now tells users that codegen requires JDK 25+, but json-java21-jtd-codegen/pom.xml and jdt2jar/pom.xml still compile with release 24, the parent profile activates on [24,), and both the top-level and codegen READMEs continue to document 24+. Either retain the 24+ minimum here or update the actual build requirement and all user documentation together so JDK 24 users are not incorrectly told the supported path is unavailable.
AGENTS.md reference: AGENTS.md:L29-L29
Useful? React with 👍 / 👎.
1 participant
What
Carries the four Issue #148 follow-up fixes that were stranded on
rel-2026.05.20after the release tag, somainis corrected before the next date-based release:jdt2jar/Dockerfilefrom JDK 24 to JDK 25 LTS.WORKDIRin the distroless stage and document thedocker cpfallback for macOS/Colima.scripts/jdt2jar.shhelper for restricted volume mount environments and clean upjdt2jar/README.md..github/workflows/ci.ymlwith the same changes.Verification
mvn -pl json-compatibility-suite,:java.util.json.jtd -am test -Djava.util.logging.ConsoleHandler.level=INFO— 451 tests, 0 failures.mvn test -Djava.util.logging.ConsoleHandler.level=INFO— all 8 modules BUILD SUCCESS.maincontains only the four intended files; no POM version bumps and no changes to the tracked ZIP test fixtures (both remain bundled and restored).Closes the follow-up work from #148 (supersedes #150, which is closed).