诊断Java代码: 平台相关性“gotcha问题” - 编程入门网
| 误
尾调用产生的平台相关性是 JVM 规范自身的产物。但是，平台相关性更常见的起因是 JVM 实现中的错误。对于 Swing 的情况，这种错误广泛存在。 例如，JDK 1.4 中的 JOptionPane 组件就一个有关的错误。如果用户把 JOptionPane 中的文本添加到紧跟在空白行后的一行中，然后按“下箭头”键，什么事也没发生。自己试试看： 打开一个新的 JOptionPane。 在 OptionPane 中，接着按 Enter 键两次。 输入“test”。 按“上箭头”键。 按“下箭头”键。 看来，上述的操作序列（以及类似的操作序列）使 JOptionPane 进入了一种奇怪的状态。如果您程序的某个用户发现了这个错误，那么它多半是通过疯狂敲击他的键盘从这种状态恢复的。（从这样一种状态中恢复并不困难；按“右箭头”键即可搞定。）一旦恢复后，他可能再不会将程序的冻结放在心上，甚至可能永远也不会报告这个错误。用户的可接受标准已经被几十年来满是错误的软件大大降低了。 而肇事者在这里。这种错误在针对我所测试的每种平台 ― Windows、Solaris 和 Linux ― 的所有 Sun JDK 1.4 版本中都存在。所以，这很可能是 Sun 的 JDK 中的一个与操作系统相关的错误。 这个示例说明，平台相关性不是仅仅与操作系统相关性有关，也不是仅仅与供应商相关性有关 ― 它与 JVM 版本相关性有关，包括向前的和向后的。 各小组通常对提供向后兼容性很关心，但他们也希望他们的代码在后来的版本中能保持其行为。理想情况下，这种期望可能是合理的，但在现实中却不然。事实上，考虑到 Sun 在提高版本 1.4 的 Swing 的性能方面付出了大量努力，给其中带来一个错误就不那么令人惊诧了。 顺便说一下，并不是只有 Sun 一家对 Swing 的性能不满意。Eclipse 项目是一个开放源代码的项目，它旨在为开发高度集成的工具提供健壮的、开放源代码的、功能全面的并且是商业级别的平台，它实现了一个全新的窗口小部件工具箱，称为 Standard Widget Toolkit（SWT）。SWT 是极轻量级的，因为，不同于 Swing，它利用了底层的特定于平台的窗口系统（windowing system）（请参阅 参考资料）。这个 API 在所有实现它的平台上是相同的，但它的观感则完全取决于平台。所以，我们可以预期，这个工具箱会有一大堆新的与平台相关的问题。 与操作系统相关的错误 作为最后一个示例，这个示例是关于您可以在 Java 平台上体会到的平台相关性的某些潜伏形式的，假设我们正在为一个编辑器编写代码，这个编辑器将打开文件并将它们读入到编辑器视窗。刚开始，我们可能编写如下代码：
对 _editorKit.read 的调用把文件的内容读入到一个临时文档，这个文档稍后将被添加到打开的文档的集合中。但是在这两行之后，我们再也没有引用 reader。 这段代码取自 DrJava IDE ― Rice 大学的免费的、开放源代码的 Java IDE ― 的早期版本（请参阅 参考资料）。现在，如果您熟悉 Split Cleaner 错误模式，那您可能已经注意到这段代码是该模式的一个很好的示例。 FileReader 被构造来读取文件的内容，但这个 FileReader 从未被关闭。当然，与 Split Cleaner 的其它实例一样，这个错误直到试图对这个文件进行其它访问为止才会出现症状。但是，尽管那样，依据平台，它有可能不出现任何症状！ 假设用户后来试图删除这个文件。在 UNIX 上，打开的文件可以被删除，所以，这个残留的、未被关闭的 FileReader 不会引起任何问题。但如果用户是在 Windows 上，则打开的文件无法被删除，所以将会有异常被抛出。我们是在我们的一个单元测试在 UNIX 上成功通过了，而在 Windows 上却通不过时发现前面代码清单中的错 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
