HADOOP-19832 Fix missing relocation for org.jspecify in hadoop-shaded-guava

[RomanVlasenko]

Closes https://issues.apache.org/jira/browse/HADOOP-19832

Problem

org.jspecify:jspecify was added as a shaded artifact in 1.5.0 but without a corresponding relocation rule. As a result, its classes are bundled at their original org/jspecify/annotations/ path inside the hadoop-shaded-guava jar.

This causes classpath collisions in projects that also have a direct or transitive dependency on org.jspecify:jspecify, since the same class files appear from two different jars.

Fix

Add a <relocation> rule for org/jspecify/ in the maven-shade-plugin configuration, consistent with how com/google/ and org/checkerframework/ are already handled.

---

For code changes:

• Does the title or this PR start with the corresponding JIRA issue id?
• Have you updated the `LICENSE`, `LICENSE-binary`, `NOTICE-binary` files? — No new dependencies added; this fix only adds a relocation rule for an already-included artifact
• If adding new dependencies to the code, are these compatible with ASF 2.0? — No new dependencies added

Use of AI

Yes — Claude (Anthropic) was used to help identify the root cause and draft this fix.

[aajisaka]

+1 for your patch. Would you open a https://issues.apache.org/jira/projects/HADOOP JIRA ticket for this?

[RomanVlasenko]

@aajisaka I've requested a Jira account. Will create the ticket there as soon as I get an access.

[pan3793]

jspecify won't be used at runtime. can we exclude it?

[RomanVlasenko]

@pan3793

jspecify won't be used at runtime. can we exclude it?

From Guava's own documentation:

In rare cases, you may also need to include the jspecify dependency at runtime. Specifically, if you run under JDK 8 and you use reflection on Guava types, you may encounter JDK-8152174. To avoid this, you can upgrade to JDK 9+, or you can stop excluding the jspecify dependency.

Source: https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies

I think it's safer to keep it.

[pan3793]

... and you use reflection on Guava types

I think we don't have such use cases in the Hadoop codebase, but I'm fine to keep it until we decide to move the baseline to JDK 17 for this repo.

[steveloughran]

+1 for keep and shade, in case guava uses.

[steveloughran]

+1

[steveloughran]

Thanks.

Added the claude mention for credit as I'd like to be able to track where it is being used...the copyright of ai generated code is really going to complicate all open source projects. Glad it helped though.