javax 包为什么叫 javax

在很多 Java 程序中，我们总能看到一个似曾相识的身影：javax。

它长得像 java，却偏偏多了一个 x，就像穿着同款外套、但坚持戴墨镜的亲戚——

它到底是谁？为什么不直接叫 java？

别急，这事儿还真有点历史包袱。

---

一切要从「扩展」说起

在 Java 早期（是的，那会儿还没有 Maven 中央仓库），官方自带的类基本都放在 java.* 包下面。这点没毛病。

后来问题来了：

有些 API 很有用，但还没成熟到「立刻进标准库」的程度，怎么办？

于是 Sun 发明了一个概念：Extension（扩展）。

这些扩展分成两类：

• 标准扩展（Standard Extension）：Sun 官方认可
• 非标准扩展：第三方提供，质量与前途全靠缘分

为了和真正的 java.* 标准库区分开来，Sun 给这些「候补选手」统一安排了一个新前缀：

javax.*

意思大概是：

「你很不错，但先在编制外干几年。」

---

为什么后来没改名？

随着时间推移，一些标准扩展表现优异：

• 用的人越来越多
• API 越来越稳定
• 大家纷纷表示：这玩意不进标准库天理难容

按理说，这时候应该把它们从 javax.* 升级成 java.*，对吧？

Sun 其实也想过这么干。

然后他们发现了一个非常现实的问题：

全世界已经有无数 Java 程序，在 import javax.xxx.*;

如果强行改名：

• 源码要改
• 文档要改
• 教程要改
• 程序员的血压要飙升

于是，在发布 Java 1.2 之后，Sun 最终选择了一个极其工程师思维的决定：

命名洁癖先放一边，兼容性保命要紧。

结果就是：

• 它们在「事实上」已经是标准库
• 但在「名字上」永远停留在 javax

所以你今天看到的 javax，本质上是：

“曾经是扩展，后来转正，但户口没迁”的 API

---

javax 里面到底装了什么？

很多人有个常见误解：

javax 里全是接口，没有实现。

这句话：一半对，一半不对。

典型情况（你最熟的那种）

在 Java EE / Jakarta EE 相关领域，确实如此：

• javax.servlet
• javax.persistence
• javax.websocket

这些包：

• 只定义接口与规范
• 不提供具体实现

你写的 Servlet 之所以能跑，是因为：

• Tomcat
• Jetty
• WebLogic

这些容器帮你实现了它们。

但并非全部如此

例如：

• javax.swing
• javax.crypto
• javax.imageio

这些包：

• JDK 本身就带了完整实现
• 并不依赖 Java EE 容器

所以更准确的说法是：

javax 里既有“规范型接口”，也有“直接可用的实现类”。

---

那为什么我下载的 JDK 里，javax 看起来不多？

原因很简单：

JDK ≠ Java EE

JDK 只会自带：

• Java SE 范围内、
• 且被认为「足够通用」的 javax 包

而大量 Java EE / Jakarta EE 相关内容：

• Servlet
• Bean Validation
• JPA

都需要你：

• 自行引入依赖
• 或使用应用服务器

换句话说：

JDK 给你的是“基础套餐”，
企业级全家桶得另外加钱（或者加依赖）。

---

从 javax 到 jakarta：时代真的变了

故事的最后一章，主角换人了。

• Java 最初由 Sun Microsystems 创建
• 后来 Sun 被 Oracle 收购
• 再后来，Oracle 将 Java EE 规范捐赠给了 Eclipse 基金会

但 Oracle 留下了一个非常关键的前提条件：

不能再使用 Java 这个名字。

于是：

• Java EE → Jakarta EE
• javax.* → jakarta.*（不是 jakartax）

从 Jakarta EE 9 开始：

• 包名发生了彻底、不兼容的变更
• 所有 javax 全部迁移为 jakarta

这一次，没有回头路，也没有兼容层。

---

总结一句话

• javax：历史原因留下的「前扩展包名」
• 它不神秘，只是年纪比较大
• jakarta：新时代的继任者，改名一次到位

如果你哪天在代码里看到：

import javax.servlet.*;

那它其实是在轻声对你说：

「我曾经是扩展，后来转正，现在退休了。」

（完）