为什么我不在类路径中使用通配符？
在我的 类路径中使用 Java 6 通配符是否有任何缺点？例如，
C:> set CLASSPATH=.\lib\*
我可以看到，如果有两个 jar 都包含具有相同路径的类，那么使用通配符可能会导致难以追踪的结果。
但除此之外，还有什么需要注意的吗？
Are there any disadvantages in using Java 6 wildcards in my classpath ? e.g.
C:> set CLASSPATH=.\lib\*
I can see that where there are two jars that both contain a class with the same path then using a wildcard may lead to results that are hard to track down.
But other than that, is there anything else to be aware of?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果这是你想做的，那就去做吧。只要你知道后果。请记住，如果其他人必须维护该项目，他们可能会将一堆 jar 复制到该文件夹中，而没有意识到默认情况下它们会被链接。不过，他们应该不会花太长时间就能看到发生了什么。
我通常会尝试尽量减少使用的 jar 文件数量，并手动将它们全部链接起来。我意识到这是个人喜好。
If it's what you want to do, then do it. As long as you are aware of the consequences. Keep in mind that if anyone else has to maintain the project, they may copy a bunch of jars into that folder not realizing that they'll be linked by default. It shouldn't take them too long to see what's going on, though.
I generally try to minimize the number of jar files I use, and link them all in manually. I realize this is personal preference.
这样做可能会加载不需要的类，并且如果同一库有两个版本；好吧，卡繁荣。
You might load undesired classes by doing so, and if there is two versions of the same library; well, kaboom.
显式类路径可以作为应用程序依赖的库（也许还有其版本！）的文档。
如果您使用通配符，您就会丢失此信息 - 如果它没有在其他地方记录，那么如果有人获得了没有
lib文件夹的应用程序副本（或者您意外删除了它），他们将遇到困难通过重复运行应用程序来跟踪所有依赖项，查看 ClassNotFoundError 并希望所有库都使用合理的包名称。An explicit classpath can server as a documentation of what libraries (and perhaps what versions thereof!) the application depends on.
You lose this if you use wildcards - if it's not documented elsewhere, then if someone gets a copy of the app without the
libfolder (or you delete it accidentally), they'll have a very hard time tracking down all the dependencies via repeatedly running the app, looking atClassNotFoundErrors and hoping that all libraries used sensible package names.您可能会为 JVM 提供很多搜索位置，这可能会在加载类时产生一些开销 - 我想聪明的 JVM 会有效地完成此操作。
You are potentially giving the JVM a lot of places to search, this might give some overhead as classes are loaded - I guess a clever JVM will do this efficiently.
我的第一反应是不要使用 env.CLASSPATH，但转念一想，在思考为什么不应该这样做时，我开始喜欢这个想法，至少对于本地开发和测试环境（至少在一段时间内）
这种方法的优点是您可以保留一个包含所有常用库（log4j、dom4j、joda time、google collections、阿帕奇公共动物园，...）。因此，您可以从 shell 编译并执行所有应用程序，而无需浪费时间输入长类路径参数。
并且您仍然可以自由使用
-cp参数，因为它取代了全局CLASSPATH设置。我永远不会在生产系统上使用它。有人更改该文件夹或 CLASSPATH 变量的内容并且我的应用程序不再工作的风险非常高。
因此，对于生产环境，类路径字符串中没有全局“CLASSPATH”和通配符。
在上述环境中使用通配符路径的缺点：一段时间后，太多项目依赖于单个库文件夹。您不知道更新库或删除旧库的副作用。对于大型应用程序，可能很难从池中找出真正需要的库。您最终可能会向产品添加未使用的库，只是因为您不确定应用程序是否可以在没有该库的情况下运行。
所以我的结论是——开发、测试、原型设计的一个不错的捷径，但对生产来说有风险。对于生产，我更喜欢（自动生成的）不带通配符的类路径字符串。
My first reflex was don't use env.CLASSPATH, but on second thought and while thinking about why one shouldn't do it I started likeing the idea, at least for a local development and test environment (and at least for a while)
The advantage of this approach is that you can keep a local folder with all your common libraries (log4j, dom4j, joda time, google collections, the apache commons zoo, ...). So you can compile and execute all your applications from the shell without wasting time typing long classpath arguments.
And your still free to use a
-cpargument, because it replaces the globalCLASSPATHsetting.I would never use it on a production system. The risk is just to high that someone changes the content of that folder or the
CLASSPATHvariable and my application doesn't work anymore.So for production, no global 'CLASSPATH' and no wildcards in the classpath string.
A disadvantage of using the wildcard path in an environment like above: After a while too many projects depend upon the single library folder. You don't know the sideeffects of updating a library or deleting an old one. And for large application it might be hard to find out which libraries from the pool are really needed. You might end up adding unused libs to the product just because you're unsure if the application will run without that lib.
So my conclusion - a nice shortcut for development, testing, prototyping but risky for production. For production I'd prefer (autogenerated) classpath strings without wildcards.