使用Sun专有的Java类是不好的做法？

Question

使用Sun专有的Java类是不好的做法？

JAR*_*ARC 26 java sun

如果使用Sun的专有Java类,编译器将显示警告.我认为使用这些类通常是一个坏主意.我在某处读到了这个.但是,除了警告之外,还有任何根本原因,你不应该使用它们吗？

Answer 1

dfa*_*dfa 54

因为它们是内部API:它们可能以未记录或不受支持的方式进行更改,并且它们绑定到特定的JRE/JDK(在您的情况下为Sun),从而限制了程序的可移植性.

尽量避免使用此类API,总是更喜欢公开记录和指定的类.

`com.sun.*`下的一些API是实验性的(例如原始的APT API).IIRC,Alex Buckley有一个关于这些API的各种状态的博客.但是,是的,一般来说,它们可能会在更新版本和供应商之间发生变化或消失. (3认同)
@FranklinYu 高级客运列车。不，apt 是注释处理工具。它短暂地拥有自己的可执行文件“apt”，现在是“javac”的一部分（“-processor”等） (2认同)

Answer 2

Pow*_*ord 22

在JDK 6文档包括标题的链接注意关于sun.*包.这是来自Java 1.2文档的文档,因此引用sun.*应该被视为他们所说的com.sun.*

最重要的一点是:

Sun公司包括了Java 2 SDK,标准版的类,分为包组java.*,javax.*, org.*和sun.*.除了sun.* 包之外的所有包都是Java平台的标准部分,并且将来会得到支持.通常,诸如sun.*Java平台之外的软件包可以在OS平台(Solaris,Windows,Linux,Macintosh等)上有所不同,并且可以随时更改,而无需通知SDK版本(1.2,1.2.1) ,1.2.3等).包含对sun.* 包的直接调用的程序不是100%纯Java.

和

实现Java平台的每家公司都将以自己的私有方式实现.这些类sun.*存在于SDK中以支持Java平台的Sun实现:这些sun.*类使Java平台类在Sun Java 2 SDK的"幕后"工作.这些类通常不会出现在另一个供应商的Java平台上.如果您的Java程序按名称请求类"sun.package.Foo",它可能会因ClassNotFoundError而失败,并且您将失去使用Java开发的主要优势.

作为"几年后"评论:由于Sun不再存在,所以不能保证`com.sun.*`不会改为`com.oracle.*`. (5认同)
顺便说一句,尝试使用`sun.*`和`com.sun.*`类将在Java 9上失败. (3认同)
那是不对的。许多`com.sun。*`软件包都是文档说明的一部分。如果没有它们，就无法编写JNDI LDAP或COSNaming代码。问题是`sun。*`软件包，它们是完全不同的事情，因此专门记录在案。 (2认同)
不是`com.sun。*`类。它们是Sun / Oracle JDK的文档部分。 (2认同)

Answer 3

Tho*_*sen 9

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

(您的代码将因ClassNotFound异常而失败)

这是确定问题的有效建议(*虽然不是正确答案*). (4认同)
+1是一个非常实用的例子,说明大多数人会认为是一个假设的未来问题 (4认同)

Answer 4

And*_*s_D 7

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

因此,您将代码耦合到特殊的Java版本,并且至少可以放松.

归档时间：	16 年，11 月前
查看次数：	13328 次
最近记录：	14 年，4 月前