为什么我不在类路径中使用通配符？

Question

在我的类路径中使用Java 6通配符有什么缺点吗？ 例如

C:> set CLASSPATH=.\lib\*

我可以看到，如果有两个罐子都包含一个具有相同路径的类，那么使用通配符可能会导致难以追踪的结果。

但除此之外，还有什么需要注意的吗？

Answer 1

如果这是你想要做的，那就去做吧。 只要你知道后果。 请记住，如果其他人必须维护项目，他们可能会将一堆罐子复制到该文件夹中，而不会意识到默认情况下它们会被链接。 但是，不应该花太多时间才能看到发生了什么。

我通常会尽量减少我使用的jar文件的数量，并手动将它们全部链接起来。 我意识到这是个人偏好。

Answer 2

您可以通过这样做加载不需要的类，如果同一个库有两个版本; 好吧，kaboom。

Answer 3

显式类路径可以作为应用程序所依赖的库（以及可能的版本！）的文档。

如果您使用通配符，则会丢失此信息 - 如果没有在其他地方记录，那么如果有人获得没有lib文件夹的应用程序副本（或者您意外删除它），他们将很难通过重复跟踪所有依赖项运行应用程序，查看ClassNotFoundError并希望所有库都使用合理的包名称。

Answer 4

你可能会给JVM提供很多搜索的地方，这可能会在加载类时带来一些开销 - 我想一个聪明的JVM会有效地做到这一点。

Answer 5

我的第一反应是不使用env.CLASSPATH ，但在第二个想法，并在思考为什么不应该这样做时，我开始喜欢这个想法，至少对于本地开发和测试环境（至少有一段时间）

这种方法的优点是你可以保留一个包含所有公共库的本地文件夹（log4j，dom4j，joda time，google collections，apache commons zoo，...）。 因此，您可以从shell编译和执行所有应用程序，而不必浪费时间键入长类路径参数。

并且您仍可以自由使用-cp参数，因为它取代了全局CLASSPATH设置。

我永远不会在生产系统上使用它。 有人改变该文件夹或CLASSPATH变量的内容并且我的应用程序不再起作用的风险很高。

因此，对于生产，类路径字符串中没有全局“CLASSPATH”且没有通配符。

在上述环境中使用通配符路径的缺点：一段时间后，太多项目依赖于单个库文件夹。 您不知道更新库或删除旧库的副作用。 对于大型应用程序，可能很难找到池中哪些库真正需要。 您最终可能会将未使用的库添加到产品中，因为您不确定应用程序是否在没有该库的情况下运行。

所以我的结论 - 开发，测试，原型设计的一个很好的捷径，但生产风险很大。 对于生产，我更喜欢（自动生成）没有通配符的类路径字符串。