如何从第三方库中剔除多余内容？
这可能不是最佳实践，但有没有办法从第三方的 jar 文件中删除未使用的类。 它查看我的类使用库的方式并进行某种覆盖率分析，然后吐出另一个 jar，其中删除了所有未受影响的类。
显然这方面存在问题。 具体来说，我提出的使用场景可能不会一直使用所有类。
但忽略这些问题，原则上可以吗？
It may not be best practice but are there ways of removing unsused classes from a third party's jar files. Something that looks at the way in which my classes are using the library and does some kind of coverage analysis, then spits out another jar with all of the untouched classes removed.
Obviously there are issues with this. Specifically, the usage scenario I put it though may not use all classes all the time.
But neglecting these problems, can it be done in principle?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
再加上这个问题，这可以提高性能吗？ 由于未使用的类不会进行 JIT 编译，从而提高了启动时间，或者 java 在编译为字节码时是否会自动检测到这一点，甚至不处理未使用的代码？
Adding to this question, can that improve performance? Since the classes not used would not be JIT compiled improving startup time or does the java automatically detect that while compiling to bytecode and do not even deal with the code that is not used?
这将是一个有趣的项目（有人已经做过了吗？）
我想您会为该工具提供您的 jar 作为起点，并提供要清理的库 jar。 它可以使用反射来确定您的 jar 直接引用哪些类，以及在调用树中间接使用哪些类（这根本不是微不足道的，但可行）。 如果它在这两个地方的任何一个地方遇到任何反射代码，它应该发出非常响亮的警告。
This would be an interesting project (has anyone done it already?)
I presume you'd give the tool your jar(s) as a starting point, and the library jar to clean up. It could use reflection to determine which classes your jar(s) reference directly, and which are used indirectly down the call tree (this is not trivial at all, but doable). If it encounters any reflection code in any of the two places, it should give a very loud warning.
jar 只是一个 zip 文件，所以我想你可以。 如果你能找到源头，那就更干净了。 也许尝试拆解该类？
jar is just a zip file, so I guess you can. If you could get to the source, it's cleaner. Maybe try disassembling the class?
在之前的工作中，我使用了 Java 混淆器，它不仅混淆了代码，还删除了未使用的类和方法。 如果您正在执行“Class.byName”或任何其他类型的反射内容，则需要告诉混淆器，因为它无法通过检查代码来判断反射调用了哪些类或方法。
当然，问题在于您不知道第三方库的其他部分是否正在执行任何反射，因此删除“未使用”的类可能会导致在您尚未测试的模糊情况下出现问题。
At a previous job, I used a Java obfuscator that as well as obfuscating the code, also removed classes and methods that weren't being used. If you were doing "Class.byName" or any other type of reflection stuff, you needed to tell the obfuscator because it couldn't tell by inspecting the code what classes or methods called by reflection.
The problem, of course, is that you don't know if other parts of the third party library are doing any reflection, and so removing an "unused" class might cause things to break in an obscure case that you haven't tested.
我为此使用 ProGuard 。 它不仅是一个出色的混淆器，还具有代码收缩阶段，可以组合多个 JAR，然后删除任何未使用的类或类成员。 它在收缩方面做得出色。
I use ProGuard for this. As well as being an excellent obfuscator, it has a code shrinking phase which can combine multiple JARs and then strip out any unused classes or class members. It does an excellent job at shrinking.
Ant 中有一个称为类文件集的工具。 您指定您知道需要的根类的列表，然后类文件集递归地分析它们的代码以查找所有依赖项。
或者，您可以开发一个好的测试套件来执行您需要的所有功能，然后在测试覆盖工具下运行测试。 该工具将告诉您实际使用了哪些类（以及其中的语句）。 与静态分析相比，这可以为您提供更小的代码集。
There is a tool in Ant called a classfileset. You specify the list of root classes that you know you need, and then the classfileset recursively analyzes their code to find all dependencies.
Alternatively, you could develop a good test suite that exercises all of the functions that you need, then run your tests under a test coverage tool. The tool will tell you which classes (and statement in them) were actually utilized. This could give you an even smaller set of code than what you'd find with static analysis.
有一种方法。
JarJar 项目就是这样做的。 JarJar 项目的第一个目标是允许将第三方库嵌入到您自己的 jar 中，并在必要时更改包结构。 这样做可以去掉不需要的类。
请访问 http://code.google.com/p/jarjar/ 查看。
这是关于收缩 jar 的链接： http://sixlegs.com/blog/java/jarjar -keep.html
There is a way.
The JarJar project does this AFAIR. The first goal of the JarJar project is to allow one to embed third party libraries in your own jar, changing the package structure if necessary. Doing so it can strip out the classes that are not needed.
Check it out at http://code.google.com/p/jarjar/.
Here is a link about shrinking jars: http://sixlegs.com/blog/java/jarjar-keep.html