Spring Boot 3 迁移中处理 javax 依赖的兼容性方案

Spring Boot 3 强制使用 Jakarta EE 9+（jakarta.）命名空间，但若第三方库（如 jira-rest-java-client-core）仍依赖 javax.，可安全共存于 classpath；无需回退或引入旧版 Jersey，但需注意 IDE 导入提示与潜在运行时冲突风险。

Spring Boot 3 强制使用 Jakarta EE 9+（jakarta.*）命名空间，但若第三方库（如 jira-rest-java-client-core）仍依赖 javax.*，可安全共存于 classpath；无需回退或引入旧版 Jersey，但需注意 IDE 导入提示与潜在运行时冲突风险。

在将项目升级至 Spring Boot 3 的过程中，最典型的兼容性障碍之一便是 Jakarta EE 命名空间迁移——所有原 javax.* 包（如 javax.ws.rs.core.UriBuilder）已正式重命名为 jakarta.*（如 jakarta.ws.rs.core.UriBuilder）。然而，像 Atlassian 官方维护的 jira-rest-java-client-core:5.2.4 这类成熟但更新滞后的第三方 SDK，目前仍基于 JAX-RS 2.x（javax.ws.rs），尚未发布 Jakarta 兼容版本。

关键结论：javax 与 jakarta 可共存，但需谨慎管理
技术上，JVM 允许 javax.* 和 jakarta.* 类型同时存在于 classpath —— 因为它们是完全不同的全限定类名（如 javax.ws.rs.core.UriBuilder ≠ jakarta.ws.rs.core.UriBuilder），不会触发类加载冲突或 NoClassDefFoundError。Spring Boot 3 的 Web 底层（如 Tomcat 10+、Jetty 12）也已原生支持双命名空间并行运行。因此，无需强行引入 jersey-client:1.x 或 javax.ws.rs-api 等遗留依赖来“补全” javax 类——这反而可能引发隐式版本冲突或资源竞争。

✅ 正确做法示例（Maven）：

<!-- Spring Boot 3.x 核心依赖（自动拉取 jakarta.*） -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<!-- 第三方 javax 依赖（保持原样） -->
<dependency>
    <groupId>com.atlassian.jira</groupId>
    <artifactId>jira-rest-java-client-core</artifactId>
    <version>5.2.4</version>
</dependency>

⚠️ 注意事项：

• IDE 提示干扰：当代码中需手动 import UriBuilder 时，IDE（如 IntelliJ）可能同时提示 javax.ws.rs.core.UriBuilder 和 jakarta.ws.rs.core.UriBuilder，务必根据实际调用方选择——本例中因 jira-rest-java-client-core 内部硬编码使用 javax，故必须选用前者。
• 避免混合使用：切勿在自定义 REST 客户端中混用 javax.ws.rs 接口与 jakarta.ws.rs 实现（例如用 jakarta.ws.rs.client.ClientBuilder 构造 client，却传入 javax.ws.rs.core.UriBuilder 实例），否则将导致 ClassCastException。
• 长期策略建议：优先关注该库的官方路线图（JRJC GitHub）；若短期内无 Jakarta 版本，可考虑轻量级封装（如通过 RestTemplate 或 WebClient 自行实现 Jira REST 调用），或采用社区维护的替代方案（如 jira-rest-java-api，已支持 Jakarta）。

总结：Spring Boot 3 迁移不必因单个 javax 依赖而停滞。务实的做法是验证当前组合在目标 JDK（17+）和容器（Tomcat 10+/Jetty 12）下的实际运行稳定性，并持续跟踪上游库更新。如项目对安全性或新特性无强依赖，亦可暂缓至 Spring Boot 3.1+（生态适配更成熟，社区方案更丰富），以降低集成风险。