我正在编写一个自定义工具来从我们的构建树构建 jar 文件。我们喜欢构建“最小”jar 文件，其中仅包含实际从“根”类（main() 所在的位置）引用的 .class 文件——依此类推，递归地遵循依赖关系。
从历史上看，我们通过让 javac 遵循源依赖关系来做到这一点，但这意味着要多次重新编译公共文件。 （我们从单个源树构建 60 或 70 个不同的应用程序 jar。）我正在编写一个新的构建系统，该系统仅编译每个源文件一次，但这意味着我们需要通过解析 .class 文件来遵循依赖关系。
好消息是，我已经有了可以完成我想要的工作的代码。但我需要绝对确定我没有搞砸，即我想确保我正在构建内部一致的 jar 文件，其中“一致”意味着所有未解析的引用都可以通过以下方式解决：我们已知的第三方罐子之一。
因此，理想情况下，我想要一个可以像这样运行的 MagicTool
MagicTool \
--classpath commons-lang.jar:commons-collections.jar:[...etc...] \
myapp.jar
，它将检查 myapp.jar 内的每个未解析的引用，并确保它可以由传递给 的第三方 jar 之一解析 - -类路径。如果没有，呕吐。
I'm writing a custom tool to build jar files from our build tree. We like to build "minimal" jar files that contain only the .class files actually referenced from the "root" class (where main() lives) -- and so on, recursively following dependencies.
Historically we have done this by getting javac to follow source dependencies, but that means recompiling common files many many times. (We build 60 or 70 distinct application jars from a single source tree.) I'm writing a new build system that compiles each source file only once, but that means we need to follow dependencies by parsing .class files.
The good news is, I've got working code that does what I want. But I need to be absolutely sure I didn't screw it up, i.e. I want to ensure that I'm building internally consistent jar files, where "consistent" means that all unresolved references can be resolved with one of our known third-party jars.
So ideally I want a MagicTool that I can run like
MagicTool \
--classpath commons-lang.jar:commons-collections.jar:[...etc...] \
myapp.jar
that will examine every unresolved reference inside myapp.jar and make sure that it can be resolved by one of the third-party jars passed to --classpath. If not, barf.
发布评论
评论（3）
最好希望该路径中没有任何内容包含任何类型的反射、
forName等。我使用 depfind（如果我没有使用自己的 Java 洞穴探险工具），它可能会也可能不会以对您有帮助的方式提供输出。 jdepend 是另一种选择，尽管我从未将其用于包级依赖项之外的任何其他用途。
其他工具（例如 ProGuard）将删除未使用的类（除其他外），并具有相同的反射警告。
我非常谨慎地避免过于努力地创建最小的 jar 文件；存在收益递减/风险增加的点。
Better hope nothing in that path includes any sort of reflection,
forName, etc.I use depfind (if I'm not using my own Java spelunking tools) which may or may not provide output in a way that's helpful for you. jdepend is another option, although I've never used it for anything other than package-level dependencies.
Other tools like ProGuard will strip out unused classes (amongst other things), with the same reflective caveats.
I'm very wary of trying too hard to create minimal jar files; there's a point of diminishing returns/increased risk.
我非常确定 ProGuard 是您的神奇工具，即使我现在不知道确切的调用语法。
I am pretty sure that ProGuard is your magic tool, even if I don't now the exact call syntax.
几年前的某个阶段，尝试使用
jar -i索引 JAR 文件会导致在存在未解决的依赖项时引发异常。我无法快速测试当前的状态。At one stage some years ago, trying to index a JAR file with
jar -imade it throw an exception if there were unresolved dependencies. I can't quickly test the current state of things.