为什么开发者写程序时不应该调用‘sun’包
来源:互联网 发布:telnet 1433端口不通 编辑:程序博客网 时间:2024/05/17 02:21
为什么程序员不应调用“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程序是不安全的,他们将变得无法移植,无法被很好地支持。
- 为什么开发者写程序时不应该调用‘sun’包
- 为什么开发者不应该在程序中调用sun.*包?
- 为什么程序员不应调用“sun”包?
- 为什么程序员不应调用“sun”包?(译文)
- 为什么程序员不应调用“sun”包?(译文)
- 为什么程序员不应调用“sun”包?支持包的类别
- 为什么程序员不应调用“sun”包?-Java基础-Java-编程开发
- 为什么应该写博客
- 为什么应该写blog
- 为什么我们应该像盖房子那样写程序?
- 为什么我们应该像盖房子那样写程序?
- 为什么我们应该像盖房子那样写程序?
- 为什么我们应该像盖房子那样写程序?
- 为什么你应该写博客
- 为什么你应该写博客
- 黑客应该怎样编程(PS:写程序跟写作文为什么有些一样)
- 为什么构造函数和析构函数中不应该调用虚函数
- WEB开发者不应该害怕的五件事
- 回答一些朋友的收掠问题(二)(转自:老公婆)
- 扩展方法Select无重载单一方式实现示例
- 模板学习笔记
- JOJ 1017 FireNet
- JVM中方法区
- 为什么开发者写程序时不应该调用‘sun’包
- 如何在桌面打开终端进行命令操作
- It's a programmer's blog
- linux2.6内核 list_head结构分析
- null与""的区别
- P2psim 源代码分析二
- C++ boost 库(先贴点资料有时间再研究)
- Linux与Windows 共享文件Samba 服务的安装于配置
- HTML DOM