search

Guardsquare / proguard

ProGuard, Java optimizer and obfuscator
https://www.guardsquare.com/en/products/proguard
GNU General Public License v2.0
2.78k stars 400 forks source link

Multi-Release JAR support #100

Open gilles-duboscq opened 3 years ago

gilles-duboscq commented 3 years ago

Currently proguard doesn't support Multi-Release JAR files and it actively filters out META-INF/versions/**.

When processing libraries, the recommended workaround](https://sourceforge.net/p/proguard/bugs/671/) is to find or crate a jar that contains the class files for the desired version.

However that doesn't help when the output of proguard should itself be a multi-release JAR.

mrjameshamilton commented 3 years ago

Hi @gilles-duboscq ! Thanks for your report. Indeed this is not yet supported but I'll tag this as enhancement and hopefully it can be added at some point.

vjay82 commented 3 years ago

This feature would be much appreciated. I read somewhere that it was not implemented because of the enormous amount of work/complexity it would impose. The current workaround is to remove all redundant/versioned files. I have a proposal for another workaround: Most libraries only have a very little amount of versioned files, which are mostly used to work around JVM issues (like the switch between 8 and 9). Why don't you leave everything around these files untouched? I mean the originals and their versions. Maybe shrink names but even without that you would still achieve an enormous overall compression without breaking libs. What I am doing now with libs, for example with Log4J2, is, to check the META-INF/versions. Build exclusions for the classes and copy the versioned files back in as a manual step. That is pretty tedious and error prone. I would gladly exchange a JAR with a few bytes more to get rid of that workflow...

Ristovski commented 3 years ago

I agree with @vjay82, there should be an option to simply copy META-INF/versions/** over to the processed jar. FWIW, I am running into the same issue with log4j as well.