| |
为什么程序员不应调用“sun”包
j2se api documents是我们最常用的参考手册，但细心的朋友可能会发现，在“%java_home%/jre/lib/rt.jar”中包含比api文档更多的类，那么其它的类为什么没有在帮助文档中出现呢？在sun的jdk faq中有一篇“why developers should not write programs that call ´sun´ packages”，该文部分地解答了这个问题，我将原文翻译如下
================================================================================
j2se中的类大致可以划分为以下的各个包：
java.*，javax.*，org.*，sun.*
除了“sun”包，其它各个包都是java平台的标准实现，并且今后也将被继续支持。一般说来，“sun”之类的包并不包含在java平台的标准中，它与操作系统相关，在不同的操作系统（如solaris，windows，linux，mac等等）中的实现也各不相同，并且可能随着j2se版本不定期变化。因此，直接调用“sun”包的程序代码并不是100％的java实现。
也就是说：
“java.*”包，“javax.*”包，“org.*”包是作为j2se的api公开接口的一部分，如果程序直接调用这些包中的api，那么程序是可以运行在所有java平台上，而与操作系统无关；但“sun.*”包并不是api公开接口的一部分，调用“sun”包的程序并不能确保工作在所有java平台上，事实上，这样的程序并不能工作在今后的java平台上。
正因为如此，“sun.*”包中的类并没有提供api文档。平台无关性是java语言最大的优势之一，此外，sun和java许可证确保维持了今后api的向上兼容性（以后修改的那些有严重bug的代码除外）。这种兼容性意味着你写好的程序编译成的cl ass文件仍然可以工作在将来的版本当中。
每家实现java平台的厂商都可以使用他们自己的方式。“sun.*”包中的类是sun 对java平台的实现方式，它们工作在java 2 sdk的下层，这些类未必被其它java 平台开发商支持。比如你的java程序如果调用了一个名为“sun.package.foo”的类，将有可能产生“classnotfounderror”的错误，同时你也将失去利用java的一个主要的优点。
从技术上讲，并不能防止你的程序调用“sun.*”包中的类。在版本的变迁当中，这些类可能会被删除或转移到其它包路径下，而且它的接口（包括名称、标签等）也很有可能发生变化，（根据sun的观点，我们应当能够通过对“sun.*”包的修改来提高java平台的性能。）在这种情况下，即便你希望程序仅仅运行在sun的实现平台下，你仍将承受新的版本给你的系统带来破坏的风险。总之，编写依赖于“sun.*”包的java程序是不安全的，他们将变得无法移植，无法被很好地支持。
|
|
