在 Java 程序中包含第三方 jar 文件的最佳实践是什么？
我有一个程序需要几个第三方库，目前它的打包方式如下：
zerobot.jar (my file) libs/pircbot.jar libs/mysql-connector-java-5.1.10-bin.jar libs/c3p0-0.9.1.2.jar
据我所知，处理第三方库的“最佳”方法是将它们放在我的清单中的类路径中jar 文件可以跨平台工作，不会减慢启动速度（捆绑它们可能会导致），并且不会遇到法律问题（重新打包可能会导致）。
问题在于自己提供第三方库的用户（示例用例，升级它们以修复错误）。其中两个库的版本号在文件中，这增加了麻烦。
我当前的解决方案是我的程序有一个引导过程，它生成一个新的类加载器并正确使用它实例化程序。此自定义类加载器将 lib/ 中的所有 .jar 文件添加到其类路径中。
我当前的方法工作正常，但我现在的应用程序中有两个自定义类加载器，并且最近对代码的更改导致了难以调试的问题，因此如果有更好的方法，我想消除这种复杂性。对于我确信是非常常见的情况，这似乎也有些过度设计。
所以我的问题是，我应该怎么做？
I have a program that needs several third-party libraries, and at the moment it is packaged like so:
zerobot.jar (my file) libs/pircbot.jar libs/mysql-connector-java-5.1.10-bin.jar libs/c3p0-0.9.1.2.jar
As far as I know the "best" way to handle third-party libs is to put them on the classpath in the manifest of my jar file, which will work cross-platform, won't slow down launch (which bundling them might) and doesn't run into legal issues (which repackaging might).
The problem is for users who supply the third party libraries themselves (example use case, upgrading them to fix a bug). Two of the libraries have the version number in the file, which adds hassle.
My current solution is that my program has a bootstrapping process which makes a new classloader and instantiates the program proper using it. This custom classloader adds all .jar files in lib/ to its classpath.
My current way works fine, but I now have two custom classloaders in my application and a recent change to the code has caused issues that are difficult to debug, so if there is a better way I'd like to remove this complexity. It also seems like over-engineering for what I'm sure is a very common situation.
So my question is, how should I be doing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想我会走明显的路线。在清单中声明条目 jar 的类路径，并包含以下条目：
然后，如果用户想要升级到最新的库版本，他们将必须重命名它们以匹配清单中声明的内容。我不认为这有什么太大的麻烦，而且它使内部的事情变得更加简单。
我通常也不喜欢自动加载 ./lib/ 中的所有内容的想法，这似乎有潜在的危险。
I think I'm going to go the manifest route. Declare the classpath in the manifest for the entry jar, and have entries for:
Then if users want to upgrade to the latest library versions, they will have to rename them to match what is declared in the manifest. I don't think that's too big a hassle, and it makes things a lot simpler internally.
I also just generally don't like the idea of loading everything in ./lib/ automatically, that seems potentially dangerous.
我们随 jar 一起提供脚本文件。例如 some.bat、some.sh 等。
从 Java6 开始，您可以使用通配符来指定类路径。
这是一篇很好的文章，解释了这种方法： https://blogs.oracle.com/mr/条目/class_path_wildcards_in_mustang
We provide script files with the jar. E.g. some.bat, some.sh etc.
And as of Java6, you can use wildcard to specify classpaths.
Here is a good article that explains this approach : https://blogs.oracle.com/mr/entry/class_path_wildcards_in_mustang
如果您的受众是技术人员（听起来他们是技术人员，如果他们愿意放入新的 jar 文件）那么也许您可以提供他们可以编辑以修改类路径的 .sh 和 .bat 文件？这对他们来说比自定义类加载器更加透明。
If your audience is technical (and it sounds like they are if they're willing to drop in new jar files) then perhaps you could supply .sh and .bat files that they can edit to modify the classpath? That will be more transparent to them than a custom classloader.
您可以尝试 Fat-Jar 解决方案，它与“Fat Jar Eclipse 插件”完美配合。我用过几个项目，没有任何问题。它的原理似乎与您当前的解决方案相同。
You can try the Fat-Jar solution, it works perfectly with the 'Fat Jar Eclipse Plug-In'. I have used for a few projects with no problems at all. The principle of it seems to be the same of your current solution.