标题: 管理 Java 类路径（UNIX 和 Mac OS X）-3 [打印本页]

---

作者: look_w    时间: 2018-5-19 15:32     标题: 管理 Java 类路径（UNIX 和 Mac OS X）-3

运行程序现在您已经成功地编译了程序，可以运行它了。运行与编译相似但更为简单一些。当运行程序时，只需指定两项内容：

• 类路径。
• 包含 main() 方法的类的完全限定包名。

无需指定源路径。
通常这里的类路径与编译程序所使用的类路径相同，只是多了一个放置编译后的输出的目录。例如，如果编译命令如下所示：

1 2 3

$ javac -d bin -sourcepath src   -classpath /Users/elharo/classes:/Users/elharo/lib/junit.jar   src/com/elharo/gui/MainFrame.java

并且 main() 方法在 com.elharo.gui.Mainframe.java 类内，就可以像这样运行此程序：

1 2 3

$ java   -classpath /Users/elharo/classes:/Users/elharo/lib/junit.jar    com.elharo.gui.MainFrame

请务必注意命令行的最后一项是类名。它不是一个文件名，也不是 .java 或 .class。该类必须能够在类路径的某处找到。
可能存在类的其他地方我强烈建议您在编译和运行时总是显式地指定类路径。也可以将文件放到其他地方，以便它们可以被添加到类路径中，并被 javac 编译器和java 解释器找到。这种做法会节省一些键入操作，但当（注意不是如果）您无意间将一个旧版本的类放到类路径中时，这却会耗费大量的调试时间。
在本节，将展示类常常隐匿其中的几个地点，这些类很可能会出乎意料地冒到类路径中并导致问题的出现。在不受您控制的机器上（比如服务器），这更为多见。
当前的工作目录编译器总是将当前工作目录 (.) 添加到类路径，而不管您是否曾显式地要求这样做。您很容易忘记在和您所在的目录相同的目录中有和没有的内容。因此，请尽量避免将任何类或层次结构放入 project 或 home 目录。相反地，应该将 .java 文件和 .class 文件分别放入 src 目录和 bin 目录。
CLASSPATH过一会，您就会发现向类路径手工添加 bin 目录和 JAR 归档文件太过繁琐。这时您可能会想要使用 CLASSPATH环境变量。可以只向 CLASSPATH 环境变量添加一次目录和 JAR 归档文件，之后就不需要在每次运行 javac 或 java 时都要再键入这些路径。
请务必抵制这种诱惑。这样做，一旦加载了错误的类或错误版本的类，就会出问题。而且意外加载错误的类所带来的调试时间常常会百倍于省下的那点键入时间。要避免输入并自动处理类路径有更好的方法。
jre/lib/ext jre/lib/ext 目录中的 JAR 归档文件会被添加到通过虚拟机运行的所有应用程序的类路径。这看起来很方便，实际上它与向 CLASSPATH 环境变量添加目录一样，存在长远的潜在问题。您迟早（通常很快）会在您想都想不到的地方加载类的一个错误版本的类并会为此付出大量的调试时间。
部署一个服务器端的应用程序时，问题就更为严峻。请确保部署到的服务器在其 jre/lib/ext 目录没有任何额外的 JAR。如果您不熟悉错误症状，也不知道该如何查找，那么由类路径中的错误版本的 JAV 归档文件所带来的问题可能会非常难于调试。为了避免这些问题的出现，一些框架甚至编写了自己的类加载器，用来绕过 Java 代码通常的类加载机制。
jre/lib/endorsedjre/lib/endorsed 目录里的 JAR 文件 也被添加到了通过虚拟机运行的所有应用程序的类路径。不同的是，这里的文件被实际放入了 bootclasspath 而不是通常的类路径，并可以代替 JDK 附带的标准类。这种方式对于在 VM 更新 XML 解析器和修复 bug 尤其有用。
但是，如前所述，这种方法看起来十分方便，但实际上也存在长期的潜在问题，原因也一样。如果需要替换 JDK 类，可以在运行时使用 -Xbootclasspath/p 选项来避免意外地加载错误版本的类。

1 2	$ java -classpath /Users/elharo/classes        -Xbootclasspath/p:xercesImpl.jar com.elharo.gui.MainFrame

自动管理类路径在想要使用电动射钉枪之前要先熟练使用锤子，与此相似，在试图采用更强大的自动管理工具之前也要先能自如地手动管理这些类。如果您掌握了命令行工具集，就可以使用另外的工具来自动处理源路径和类路径所需的一些繁琐过程。这些工具大部分也需要您像本文所介绍的那样组织文件。
IDE像 Eclipse 和 NetBeansMost 这样的许多开发环境都能协助类路径的自动管理。例如，当更改包的名称时，Eclipse 能相应地移动对应的 .java 文件，如图 5 所示：
图 5. 在 Eclipse 中快速修复类路径请记住，这些 IDE 位于文件系统的顶部，必须正确设置，尤其是当需要与其他工具和其他 IDE 集成时就更应如此。这些工具最大的贡献是用 GUI 对话框、树视图和选项卡代替了命令行开关参数，但其基本的文件结构还是一样的。
AntAnt 是自动化构建过程的事实上的标准工具。与将目录放在 jre/lib/ext 或 CLASSPATH 环境变量的做法不同，Ant 真的可以让您创建单步的构建过程。但您仍然需要在 Ant build.xml 设置类路径并手动将源文件放到正确的目录。但至少现在您无需在每次编译都要重新进行指定。
MavenMaven 在组织和自动化构建过程方面比 Ant 还要更进一步。Maven 提供一个合理的默认设置让您可以通过添加少许几行代码并将源文件放到 Maven 能够找到的位置即可构建简单的项目。您仍然需要调整文件系统和包的层次结构。Maven 在管理第三方库的依赖性方面也有上佳的表现，虽然它不如 Ant 那么易于定制。                       
结束语不管类路径有多么棘手，您都可以通过一些简单的规则对它加以管制，尤其是要记住如下的一些原则：

• 将类放到包中。
• 严格遵守包和类的命名约定和大小写约定。
• 确保包的层次结构与目录的层次结构匹配。
• 总是对 javac 应用 -d 选项。
• 不要在 jre/lib/ext 内放任何东西。
• 不要在 jre/lib/endorsed 内放任何东西。
• 不要将 .java 文件与 .class 文件放在同一个目录。
• 不要将任何 .java 或 .class 文件放在当前的工作目录。

最后一点提示：很多耗时的类路径问题的起因大都是目录名拼写错误或从错误目录进行了编译。如果您不能找到问题的所在，可以问问周围的朋友或同事。以我的经验，自己发现自己的错误总是困难的，但这些错误在别人看来却显而易见。所以寻求他人的帮助也是一种切实有效的调试技巧。
类路径确实不是个简单的问题，但总会有相应的应对方法，所以它是完全可管理的。些许的谨慎加上对本文所介绍的命名约定、命令行参数和目录结构的注意，应该能够使您在问题最少的情况下编译和运行程序了。

---

欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)

Powered by Discuz! 7.0.0