Question

在classpath中使用Java 6通配符有什么缺点吗？ e.g。

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'，并且类路径字符串中没有通配符。

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

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