How to remove fluff from a third-party library?

This may not be the best practice, but there are ways to remove unused classes from third-party jar files. Something that looks at how my classes use the library and does some kind of coverage analysis, then spits out another jar with all the classes removed.

Obviously there are problems with this. In particular, the use case that I used may not use all classes all the time.

But neglecting these problems, can this be done in principle?

+4
source share
7 answers

There is a way.

The JarJar project is being implemented by AFAIR. The first goal of the JarJar project is the ability to embed third-party libraries in your bank, changing the package structure if necessary. This may deprive 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

+8
source

Ant has a tool called classfileset. You list the root classes that you know, and then classfileset recursively analyzes your code to find all the dependencies.

Alternatively, you can develop a good test suite that will perform all the functions you need, and then run the tests as part of the testing tool. The tool will tell you which classes (and the operator in them) were actually used. This can give you an even smaller set of code than what you will find in static analysis.

+2
source

I use ProGuard for this. Besides an excellent obfuscator, it has a code reduction phase that can combine multiple JARs and then highlight any unused classes or class members. It does an excellent job in compression.

+2
source

In the previous assignment, I used Java-obfuscator, which also messed up the code, and also deleted classes and methods that were not used. If you were doing "Class.byName" or some other reflection material, you had to tell the obfuscator because he could not tell by checking the code which classes or methods are called by the reflection.

The problem, of course, is that you don’t know if other parts of the third-party library make any thought, and therefore deleting the “unused” class may lead to something breaking in an unclear case, t.

+1
source

jar is just a zip file, so I think you can. If you could get to the source, it would be cleaner. Maybe try to parse the class?

0
source

Adding to this question, can this improve performance? Since classes that were not used would not have been compiled by JIT to improve startup time, or does java automatically detect that when compiling to bytecode and does not even deal with code that is not used?

0
source

It would be an interesting project (has anyone done this already?)

I assume that you will provide the tool with your can (s) as a starting point and the library can for cleaning. It can use reflection to determine which classes your jar (s) are referencing directly, and which are used indirectly down the call tree (this is not trivial at all, but doable). If he meets any reflection code in any of two places, he should give a very loud warning.

0
source

Source: https://habr.com/ru/post/1276507/


All Articles