Match a distribution whose candidate carries a vendor build

[jkschneider]

UpdateSdkManTest has four failures on main, which fail every open PR. They are not caused by any of them.

What happened

The automated candidate refresh ([Auto] SDKMAN! Java candidates as of 2026-08-24T1031, 4d52274) changed identifiers to carry the vendor build:

-11.0.32-zulu     +11.0.32+1.1-zulu
-17.0.20-zulu     +17.0.20+1.1-zulu

38 of the 92 candidates now have one, across -zulu, -ms and -librca.

Why it breaks distribution matching

VersionComparator.RELEASE_PATTERN captures the qualifier as (?<qualifier>[-.+].*?$), so it begins at the first -, . or +. The recipe passes the distribution to LatestRelease as the metadata pattern, and checkVersion requires the whole qualifier to match it:

candidate	qualifier	matches -zulu
17.0.20-zulu	-zulu	yes
17.0.20+1.1-zulu	+1.1-zulu	no

Every candidate for the requested distribution is filtered out, no ideal candidate is found, and the recipe makes no change — which is what the four tests report.

Fix

Tolerate a build ahead of the distribution when matching:

private static final String BUILD_METADATA = "(\\+[^-]*)?";

Deliberately narrow rather than .*. A distribution variant is also part of the qualifier — .crac-zulu is a different distribution from -zulu, and zuluNonCrac exists to assert that a plain request does not select the CRaC build. .*-zulu would match it and quietly break that guarantee; (\+[^-]*)?-zulu cannot, because a variant does not begin with +.

The same pattern is used for the downgrade check, so both sides of the comparison agree on what the distribution is.

Tests

distributionIsStillMatchedWhenTheCandidateCarriesAVendorBuild covers an .sdkmanrc that already pins a build, and zuluNonCrac gains an explicit doesNotContain(".crac") so the narrowness above is asserted rather than assumed.

Reverting only the main source fails five tests including the two above; with the fix, UpdateSdkManTest is 18/18 and the full suite is green.

Worth noting separately

An fx candidate now reads 11.0.32-fx+1.1-librca, where the build sits after the variant. A request whose distribution is .fx-librca still will not match it, since the build is not adjacent to the distribution in that layout. No test covers that shape today and none of the current failures involve it, so it is left alone here rather than guessed at.