Skip to content

Reduce full JAR size by removing unused Bouncy Castle versioned payload - #82

Merged
BenCodez merged 1 commit into
mainfrom
codex/reduce-bc-jar-payload
Sep 12, 2026
Merged

Reduce full JAR size by removing unused Bouncy Castle versioned payload#82
BenCodez merged 1 commit into
mainfrom
codex/reduce-bc-jar-payload

Conversation

@BenCodez

Copy link
Copy Markdown
Owner

Summary

Conservative size reduction for the existing full SimpleAPI.jar, following the growth from HTTP transport PR #73.

  • Filter only META-INF/versions/** from org.bouncycastle:* during shading. The full artifact is not a multi-release JAR; these alternative implementations cannot be selected by its existing manifest.
  • Keep all base Bouncy Castle classes/resources, including reflectively loaded provider mappings. Keep minimizeJar=false, all dependency versions/scopes, HTTP implementation, public APIs, full/shared classifiers, and the single Maven project unchanged.
  • Add package-phase FullArtifactTest: verify the manifest, absence of versioned BC payload, and preservation of every base org/bouncycastle/ entry from the three resolved BC libraries. Report the final JAR size and compressed upstream payload omitted, without a pinned dependency version or invented byte reduction.
  • Add a fresh-JVM smoke test using only the actual shaded JAR plus one fixture class. Exercise CA/server/client certificate creation, PKCS12, mutual TLS, rejection of missing/foreign credentials, backend identity checks, persistence reload, and server/CA renewal. Socket, worker, and subprocess waits are bounded.
  • Document packaging boundaries and measurement under docs/jar-packaging.md.

This does not remove the HTTP dependency cost entirely, move dependencies to provided, download libraries at runtime, or recreate Maven submodules. No production Java source or GitHub workflow is changed. Downstream artifacts that separately re-shade the original transitive BC JARs may reintroduce the versioned payload; this PR targets the SimpleAPI distribution itself.

Validation performed before opening

  • Reconstructed baseline POM exactly matches upstream blob 3b9eae8e1fdad8f1eac2a5e3c971c9a7eda28fdf.
  • XML/invariant checks passed: dependencies, repositories, versions, publication profiles, compiler and classifier configuration are unchanged; the sole payload exclusion is BC-specific.
  • git diff --check: passed.
  • Java 21 syntax/type-shape compilation of both new test sources against temporary API stubs: passed. Confirmed the child fixture requires exactly one class file. This is not a project compilation, real dependency test, or TLS runtime result.
  • Source/diff inspection completed in the implementation context; no independent clean review is claimed.

Build/review gates still required

Local mvn -B -f SimpleAPI/pom.xml package was attempted but could not run (mvn: command not found). The editing container also could not resolve GitHub for a normal clone and could not download Maven dependencies. Consequently this is a draft pending the existing GitHub Maven workflow, the packaged-runtime checks, independent review, and the maintainer's preferred local validation. No successful local Maven build, measured output size, or downstream build is claimed.

The existing workflow runs mvn -B -f SimpleAPI/pom.xml package without skipping tests and will execute the new package-phase checks. Exact baseline/candidate output-size comparison requires clean builds with the same resolved dependencies and JDK; the test's upstream ZIP-byte counter is explicitly not that exact difference.

Base: 32e592dc722958fcc18c214971be71446b6e8793
Candidate: 0f6fb900e28e17eb2f536dcfe4d24f789cc2c951

Copy link
Copy Markdown
Owner Author

@codex review

Please review the BC-only multi-release payload filter and the packaged-JAR TLS regression checks. In particular, verify that no active base/provider classes are lost, the artifact manifest contract is correct, and the fresh JVM cannot accidentally use Maven dependencies. The HTTP implementation and dependency scopes are unchanged. This is a draft; local Maven was unavailable, so do not treat the documented syntax checks as a successful package build.

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 12, 2026

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review Completed 2026-09-12T21:23:40.324263Z 0f6fb90 Draft marked ready
🔒 Security Review Completed 2026-09-12T21:27:12.768949Z 0f6fb90 Draft marked ready
ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: 0f6fb900e2

ℹ️ 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".

@BenCodez
BenCodez marked this pull request as ready for review September 12, 2026 21:21
@BenCodez
BenCodez merged commit 1195bf9 into main Sep 12, 2026
4 checks passed
@BenCodez
BenCodez deleted the codex/reduce-bc-jar-payload branch September 12, 2026 21:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant