Cover legacy Bouncy Castle artifacts and their API changes

[timtebeek]

What

BounceCastleFromJdk15OntoJdk18On only handled -jdk15on and -jdk15to18, and neither Bouncy Castle recipe touched code. Since the dependency change pins latest.release, users land on 1.85.2 in a single hop, where some of their code no longer compiles.

Dependency coordinates

Added every legacy suffix that has a published counterpart, to both the jdk18on recipe (Java 8+) and the jdk15to18 recipe (Java < 8):

suffix	artifacts
-jdk16	bcprov, bcprov-ext, bcmail, bcpg
-jdk15+	bcprov, bcmail, bcpg
-jdk15	bcprov, bcprov-ext, bcmail, bcpg
-jdk14	bcprov, bcprov-ext, bcutil, bcpkix, bcmail, bcpg, bctls
-jdk12	bcprov, bcpg

Only pairs that actually exist on Maven Central are listed — there is no bcjmail-jdk14, and bcpkix/bcutil/bctls never shipped -jdk15/-jdk15+/-jdk16.

bctsp-* is frozen at 1.46 and was folded into bcpkix at 1.47, so all five surviving suffixes map onto bcpkix. This is not a suffix swap, so the concern was duplicate coordinates — but ChangeDependency already collapses those, verified end to end: a pom holding both bctsp-jdk15on:1.46 and bcpkix-jdk15on:1.70 comes out with a single bcpkix-jdk18on element. bctspAlongsideBcpkixCollapsesToASingleDependency asserts both the resolved model and that the raw XML contains the artifact exactly once.

bcprov-ext is also added to the pre-existing -jdk15on and -jdk15to18 sections in both recipes; migrating bcprov-jdk15on while leaving bcprov-ext-jdk15on behind was an oversight. Note bcprov-ext-jdk18on stops at 1.78.1 while bcprov-jdk18on is at 1.85.2 — still an upgrade, just not to current.

API changes

I diffed the public/protected API of bcprov/bcpg/bcpkix/bctls/bcutil/bcmail at jdk15on 1.70 against jdk18on 1.85.2 by parsing the class files. Two findings were worth automating:

BouncyCastleDerStringGetInstanceReturnType — 1.71 pulled getInstance(..) up from the 12 DER*String types to their ASN1*String supertypes. The call site still compiles, because static methods are inherited; what breaks is the return type:

ASN1IA5String s = DERIA5String.getInstance(o);   // fine in both
DERIA5String  s = DERIA5String.getInstance(o);   // compiles at 1.70, breaks at 1.85

So the recipe widens the declared type rather than retargeting the call. Both the DER* and ASN1* types exist with identical getInstance signatures at 1.70, so this compiles against either artifact and can be applied ahead of the upgrade. A blanket ChangeType is not an option — the ASN1*String types are all abstract, so new DERIA5String(..) has to stay.

BouncyCastleSphincsPlusToPqcLegacy — 1.78 moved org.bouncycastle.pqc.crypto.sphincsplus to org.bouncycastle.pqc.legacy.sphincsplus to free the original package for FIPS 205 SLH-DSA. All 19 types map 1:1, so it is a plain ChangePackage.

Not covered

Deliberate omissions, all verified against the same diff:

• ASN1TaggedObject.getObject() / getObjectParser(int, boolean) — genuinely removed. Replacements (getBaseObject(), getExplicitBaseObject()) exist at 1.70, but the correct one depends on whether the tag is explicit or implicit, and guessing wrong is a silent parsing bug rather than a compile error. Better as a search recipe.
• ASN1ApplicationSpecific family — deleted; the replacement is ASN1TaggedObject + BERTags.APPLICATION, a structural rework rather than a rename.
• McEliece, GMSS, qTESLA, pqc.math.linearalgebra, oer.its — removed outright, nothing to migrate to.
• TLS and OpenPGP operator SPI removals — protected extension points that only affect custom crypto provider implementations. The high-level org.bouncycastle.openpgp API and BouncyCastleProvider have zero public member removals across 1.70 → 1.85.

Testing

BouncyCastleTest goes from 21 to 76 cases; versions are pinned per suffix to one that actually resolves (1.70 for jdk14/jdk15on/jdk15to18, 1.46 for jdk15/jdk15+/jdk16/bctsp, 130 for jdk12), since the previously hardcoded 1.70 does not exist for the older artifacts. New BouncyCastleApiTest covers the two code recipes, including that constructors are left alone.

Full suite green: 1844 tests, 0 failures.

One wart worth flagging: alreadyDeclaredAsAsn1String needs expectedCyclesThatMakeChanges(1) even though the printed source is unchanged, because upstream ChangeMethodInvocationReturnType re-attributes the invocation type on every match. Harmless in a real run — no diff is produced — but it may be worth an upstream issue.

recipes.csv regenerated with ./gradlew rCG.