#671 Failure to read multi release jars

[Code Buddy]

The latest version of a library we depend on has updated its jar to be multi release. When reading this library jar, we now get the following error which prevents us from being able to build:

Can't process class [META-INF/versions/9/com/teamdev/jxbrowser/chromium/internal/JavaVersion.class] (Unsupported class version number [53.0] (maximum 52.0, Java 1.8)))

I can see from ticket 551 that Pro Guard doesn't yet support Java 9. The class files in this library are all major version 50 (Java 6) except those in META-INF/versions/9/.

Short of full Java 9 support, would a stepping stone be to just ignore class files in META-INF/versions/ so multi release jars can be supported? Or is there another work around that exists today perhaps?

The only workaround I've come up with so far for this is to remove the META-INF/versions/ folder from the jar.

[Eric Lafortune]

ProGuard 6.0 (currently beta 1) supports Java 9 class files. However, at this time, it does not support multi-release classes. You could remove them or filter them out:

-injars input.jar(!META-INF/versions/**)

[Code Buddy]

Thank you very much for the workaround. We're referencing this libraray using -libraryjars and I can confirm that this work around works for this option as well. Now to get it working with the proguard-maven-plugin!

[Mark Balliet]

I just looked over the code for the proguard-maven-plugin, it doesn't look like there's a way to do this without specifiying all the library files manually. The code would be easy to update however so that it could have a filter passed in for each library.

[i-pk-pjers-i]

Has any progress been made on this? I have a multi-release jar that I build with IntelliJ IDEA which uses multi-release for log4j2 just fine when I add Multi-Release: true to the MANIFEST.MF file that IntelliJ IDEA uses. However, when I use ProGuard, even if I tell it to keep the MANIFEST.MF files and even if I add the log4j2 library jars as injars or libraries with (!META-INF/versions/**) or even just add (!META-INF/versions/**) to my main injar that builds into an obfuscated outjar - I believe it looks like it does keep the class files however log4j2 in my application log still throws this warning: WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance. after obfuscating with ProGuard. The IntelliJ multi-release jar file that I build works just fine until I obfuscate it. I'm on Java 11 on Ubuntu 18.04 but I can replicate this issue on Ubuntu 16.04 as well. I am using ProGuard 6.1.0 stable.

Is this something that can still be looked into, or perhaps am I doing something wrong? I don't think I'm doing anything wrong, though, but I'm happy to provide any other information.

[Eric Lafortune]

ProGuard 6.1.0 still doesn't support multi-release classes. You still need to filter them out of your input jars and library jars. If you add log4j as a library jar, you can add its original jar to the obfuscated application (because it is not processed and included in the output). Hopefully, the presence of the different class versions then avoids this warning.

[i-pk-pjers-i]

Hi,

Are there any plans to support multi-release jars in the future? I think they are the best option going forward. I tried using the latest log4j2 as an injar on it's own, as a part of my main injar, and as a library jar, all with the proper filter. None of them worked and the warning was still produced.

Thanks.

[Gilles Duboscq]

Support for processing multi-release jars would be very helpful

[Doug Simon]

+100!

[FxT]

+1 vote

[T. Neidhart]

Support for processing multi-version jars would require a lot of work.
The next release 6.2.1 has default filters to exclude META-INF/versions/** by default, to prevent errors.

The best option is to use jars that contain the version of the classes that you want to use and process that with ProGuard.

[i-pk-pjers-i]

I'm still having issues with this even with 6.2.1.

I get this lovely output in my console: https://i.imgur.com/kihYzjY.png
2019-12-07 20:00:51,156 main ERROR PatternLayout contains an invalid element or attribute "pattern"

when an obfuscated application attempts to read my log4j2.xml file: https://pastebin.com/C0hQkTMY - even though the logger.error("Yes") still prints to the console, as you can see in the picture I linked - it's missing my custom pattern for date/time.

Here is my ProGuard configuration: https://pastebin.com/3FXyezDn

Keep in mind, this works pefectly before passing the application through ProGuard, so I don't believe it's a log4j2 issue.

I'm not sure if I'm doing something wrong, and my issue is unrelated to not being able to read multi release jars (even though I'm on Java 11 so it might be anyway) so I dunno.

I tried this in my code so that it loads the log4j2 file properly (even though, I think it is above, since it recognizes that I have a PatternLayout):
System.setProperty("log4j.configurationFile","./log4j2.xml");

but that only throws an error of:
ERROR StatusLogger File not found in file system or classpath: ./log4j2.xml
ERROR StatusLogger Reconfiguration failed: No configuration found for 'AsyncContext@4b85612c' at 'null' in 'null'

I know I'm not the only person having problems using ProGuard with log4j2, especially under Java 11, I'd love some insight on this if possible.

Cheers.

[T. Neidhart]

Can you share a small sample illustrating your problem?
The obfuscated jar would also be helpful. I also dont know what configuration you are using, maybe the log4j2.xml file gets corrupted during processing or is not correctly included in the output jar.

[i-pk-pjers-i]

Hi,

If you're replying to my comment, I posted a picture of my issue, as well as the exact configuration of log4j2.xml as well as my ProGuard configuration. The log4j2.xml seems like it is being read properly, which is why it detects that there is a PatternLayout tag. You can see the log4j2.xml exists in the jar here: https://i.imgur.com/eoRjDLU.png

Cheers.

[T. Neidhart]

I dont know the contents of the jar file that you are willing to obfuscate, does it also include log4j2 itself?

Log4j2 uses reflection a lot, it is likely that due to obfuscation some things do not work properly anymore, its suggested to add a rule like this:

-keep class org.apache.logging.log4j.* { ; }

[i-pk-pjers-i]

Hi,

Yes, it includes log4j2.xml - log4j2 does attempt to read the log4j2.xml file which is why it throws a warning/error when trying to read the PatternLayout pattern element.

I do have keep class for all of the libraries like disruptor and log4j2.

Cheers.

[T. Neidhart]

ok please create a separate ticket for this and include all necessary information to reproduce the issue. This does not seem to be related to versioned classes inside jar files.