如果使用Sun专有的Java类,编译器会显示警告。我认为使用这些类通常是一个坏主意。我在某处读到了这个。但是,除了警告之外,还有任何根本原因,你不应该使用它们吗?
答案 0 :(得分:52)
因为它们是内部API:它们可能会以未记录的或不支持的方式发生变化,并且它们会绑定到特定的JRE / JDK( Sun < / strong>在您的情况下),限制程序的可移植性。
尽量避免使用此类API,总是更喜欢公开记录和指定的类。
答案 1 :(得分:22)
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开发。
答案 2 :(得分:9)
尝试使用非Sun JVM运行代码,看看会发生什么......
(您的代码将因ClassNotFound异常而失败)
答案 3 :(得分:7)
是的,因为没有人保证这些类或API与下一个Java版本相同,我敢打赌,不能保证这些类在其他供应商的Java版本中可用。
因此,您将代码耦合到特殊的Java版本,并且至少可以放松。
答案 4 :(得分:4)
Sun的专有Java类是他们的Java实现的一部分,不是Java API的一部分,它们的使用没有文档记录且不受支持。由于它们是内部的,因此可以随时更改由Sun JVM工作的团队决定的任何原因。
Sun的Java实现并不是唯一的实现!您的代码无法从其他供应商(如Oracle / BEA和IBM)移植到JVM。
答案 5 :(得分:2)
答案 6 :(得分:1)
我最近有一个案例显示了当你使用这些类时可以遇到的现实世界问题:我们的代码无法编译,因为它在sun上使用的方法。*类在OpenJDK中根本不存在Ubuntu Linux系统。所以我想在使用这些类时你不能再说“这适用于Java 5”,因为它只适用于某个Java实现。