[java] Prevent byte-buddy -jdkN variant from being picked by dependency updates

[pierluigilenoci]

Description

Byte Buddy publishes -jdkN compatibility variants alongside its regular releases. Maven Central indexes those variants as newer than the regular release (e.g. 1.18.8-jdk5 sorts higher than 1.18.8), so the automated dependency update task (rake_tasks/java.rake — java:update, called from ./go all:update) keeps picking the -jdkN flavor even though Selenium targets Java 8+ and only needs the regular release.

The Maven enforcer plugin then complains because 1.18.8-jdk5 sorts as greater than the managed dependency 1.18.8.

This was first fixed in #17382 by reverting MODULE.bazel to 1.18.8. The next automated dependency update silently reintroduced 1.18.8-jdk5, which is what #17355 reports.

Fix

Add a guard in the java:update Rake task that detects net.bytebuddy:* artifacts whose proposed version carries a -jdkN suffix and falls back to maven_stable_release(artifact), which already filters to versions matching \A\d+\.\d+(\.\d+)*\z and therefore excludes any -jdkN variant.

The guard mirrors the existing graphql exception in the same loop.

Also revert MODULE.bazel from 1.18.8-jdk5 back to 1.18.8 and re-pin java/maven_install.json so the repo state is consistent again.

Changes

• rake_tasks/java.rake — add net.bytebuddy:* -jdkN guard in java:update (calls maven_stable_release instead of using the version returned by @maven//:outdated)
• MODULE.bazel — 1.18.8-jdk5 → 1.18.8
• java/maven_install.json — regenerated via RULES_JVM_EXTERNAL_REPIN=1 bazel run @maven//:pin

Verification

• Re-pinned successfully: byte-buddy:jar lockfile metadata now reads "version": "1.18.8".
• The new branch in versions.each matches the format of the existing graphql exception, so it is covered by the same next if version.nil? safety net when maven_stable_release cannot resolve.

Fixes #17355

Status: draft until CI is green.

[titusfortner]

Thanks for the fix!

[titusfortner]

CI "failure" is unrelated, I'm going to merge it.

[qodo-code-review]

Review Summary by Qodo

Prevent byte-buddy -jdkN variant from being picked by dependency updates

🐞 Bug fix

Walkthroughs

Description

• Add guard in java:update Rake task to prevent byte-buddy -jdkN variants
• Revert MODULE.bazel from 1.18.8-jdk5 back to 1.18.8
• Re-pin java/maven_install.json with correct byte-buddy version
• Mirrors existing graphql exception pattern for stable release detection

Diagram

flowchart LR
  A["Automated Dependency Update"] -->|detects -jdkN suffix| B["net.bytebuddy Guard"]
  B -->|calls maven_stable_release| C["Stable Release Filter"]
  C -->|returns 1.18.8| D["MODULE.bazel Updated"]
  D -->|re-pins| E["maven_install.json"]

Loading

File Changes

1. rake_tasks/java.rake 🐞 Bug fix +8/-0

Add byte-buddy -jdkN variant guard in java:update task

• Added conditional guard for net.bytebuddy:* artifacts with -jdkN suffix
• Falls back to maven_stable_release() to filter out JDK variant versions
• Follows same pattern as existing graphql exception with nil safety check
• Prevents Maven enforcer plugin conflicts from version sorting issues

rake_tasks/java.rake

---

2. MODULE.bazel ⚙️ Configuration changes +1/-1

Revert byte-buddy to stable 1.18.8 release

• Reverted net.bytebuddy:byte-buddy version from 1.18.8-jdk5 to 1.18.8
• Ensures consistency with Selenium's Java 8+ target and stable release requirement

MODULE.bazel

---

3. java/maven_install.json Dependencies +14/-14

Re-pin maven_install.json with stable byte-buddy version

• Updated net.bytebuddy:byte-buddy version metadata from 1.18.8-jdk5 to 1.18.8
• Regenerated lockfile checksums for jar and sources artifacts
• Updated multiple dependency checksums due to re-pinning operation
• Reflects consistent state after reverting to stable byte-buddy release

java/maven_install.json

---