使用 Sun 的专有 Java 类是一种不好的做法吗？答案

【问题标题】：It is a bad practice to use Sun's proprietary Java classes?使用 Sun 的专有 Java 类是一种不好的做法吗？
【发布时间】：2010-12-22 12:47:00
【问题描述】：

如果您使用 Sun 的专有 Java 类，编译器会显示警告。我认为使用这些类通常是个坏主意。我在某处读过这个。但是，除了这些警告之外，还有什么根本原因不应该使用它们吗？

【问题讨论】：

任何足够通用的功能都将体现在官方 Java API 中。 Sun 类中是否真的有一些您需要并且无法通过标准 Java API 完成的东西？能举个例子吗？
（我有时会发现自己使用内部 xerces 进行 xml 处理）
在使用 JAXP 处理 XML 时，xerces 是默认的 XML 实现。无需伸手直接使用xerces。
我发帖的原因是因为我遇到了一些使用 sun.misc.BASE64Decoder 的代码。我将其更改为使用来自 apache 的编解码器。我知道这是正确的做法，但不记得为什么。
我想整天抱怨这些类导致了 IKVM.NET 中 80% 的问题。

标签： java sun

【解决方案1】：

这是甲骨文的回答：Why Developers Should Not Write Programs That Call 'sun' Packages

【讨论】：

虽然这在理论上可以回答这个问题，it would be preferable 在此处包含答案的基本部分，并提供链接以供参考。

【解决方案2】：

尝试使用非 Sun JVM 运行您的代码，看看会发生什么...

（您的代码将因 ClassNotFound 异常而失败）

【讨论】：

这是识别问题的有效建议（虽然不是正确的答案）。
+1 非常实用地说明了大多数人认为未来的假设问题

【解决方案3】：

我最近有一个案例显示了使用这些类时可能遇到的实际问题：我们的代码无法编译，因为它在 sun.* 上使用的方法在 OpenJDK 中根本不存在Ubuntu。所以我想在使用这些类时，你不能再说“这适用于 Java 5”之类的话，因为它只适用于特定的 Java 实现。

【讨论】：

我强烈建议您在与用于开发不同的平台和 JVM 上运行您的单元测试。很多有趣的事情往往会出现。

【解决方案4】：

JDK 6 Documentation 包含一个标题为 Note About sun.* Packages 的链接。这是来自 Java 1.2 文档的文档，因此对 sun.* 的引用应该被视为他们说的是 com.sun.*

其中最重要的几点是：

Sun 包含的类 Java 2 SDK，标准版，秋季进入包组java.*，javax.*， org.* 和 sun.*。除了sun.* 包是标准的一部分 Java 平台，将被支持进入未来。一般来说，包例如sun.*，在 Java 平台，跨平台可能不同操作系统平台（Solaris、Windows、Linux、 Macintosh 等），并且可以随时更改 SDK版本的时间恕不另行通知（1.2、1.2.1、1.2.3 等）。程式包含对sun.* 的直接调用包不是 100% 纯 Java。

和

每个实施 Java 的公司平台会自己做私人方式。 sun.* 中的类是存在于 SDK 中以支持 Sun Java平台的实现： sun.* 类是什么使 Java 平台类工作“在适用于 Sun Java 2 SDK。这些课程一般不会出现在另一个供应商的 Java 平台上。如果你的 Java 程序要求一个类 “sun.package.Foo”的名称，它可能会失败使用 ClassNotFoundError，您将失去了主要优势用 Java 开发。

【讨论】：

作为“若干年后”的评论：不能保证 com.sun.* 不会更改为 com.oracle.*，因为 Sun 不再存在。
这不正确。许多com.sun.* 包是文档化规范的一部分。没有它们就不可能编写 JNDI LDAP 或 COSNaming 代码。问题是 sun.* 包，这是一个完全不同的问题，并专门记录为这样。
顺便说一句，尝试使用 sun.* 和 com.sun.* 类将在 Java 9 上失败。
不是com.sun.* 类。它们是 Sun/Oracle JDK 的文档化部分。
我知道sun.* 是内部的，但有没有关于com.sun.* 是内部的消息来源？有没有任何版本的com.sun.* 包被破坏的例子？

【解决方案5】：

因为它们是内部 API：它们可能会以未记录或不受支持的方式进行更改，并且它们绑定到特定的 JRE/JDK (Sun 在你的情况下），限制了你的程序的可移植性。

尽量避免使用此类 API，始终更喜欢公开记录和指定的类。

【讨论】：

com.sun.* 下的一些 API 是实验性的（例如原始的 APT API）。 IIRC，Alex Buckley 有一篇关于这些 API 的各种状态的博客。但是，是的，一般来说，它们可能会在更新版本和供应商之间发生变化或消失。
我已将我的 java 编辑器 (IntelliJ Idea) 设置为从智能感知建议中排除 com.sun。谢谢您的建议。
@TomHawtin-tackline “APT”是指Academic Progress Tracker吗？
@FranklinYu 高级旅客列车。不，apt 是注释处理工具。它短暂地拥有自己的可执行文件apt，现在是javac 的一部分（-processor 等）

【解决方案6】：

Sun 的专有 Java 类是其 Java 实现的一部分，而不是 Java API 的一部分，它们的使用未记录且不受支持。由于它们是内部的，因此可以根据 Sun JVM 团队决定的任何原因随时更改它们。

Sun 的 Java 实现也不是唯一的！您的代码将无法移植到 Oracle/BEA 和 IBM 等其他供应商的 JVM。

【讨论】：

【解决方案7】：

是的，因为没有人保证这些类或 API 将与下一个 Java 版本相同，我敢打赌，不能保证这些类在其他供应商的 Java 版本中可用。

因此，您将您的代码与特殊的 Java 版本结合起来，至少失去了可移植性。

【讨论】：