#620 Obfuscation issue with lambda

[Renault Matthieu]

Hello, i got confused into an issue with Proguard (sorry by advance for the grammaR, i'm French)

My issue happen with an interface (also its a FunctionalInterface) which is located into a library, i obfuscate this library and save mapping. Then i obfuscate a project who use this library, i apply the previously generated mapping, when i launch the resulting jar i got an AbstractMethodError.

So, it is possible to do this?

Thanks, cordially
Matthieu

[Eric Lafortune]

ProGuard should indeed apply the previously created mapping from the library, keeping the application consistent. However, one can imagine cases where it is impossible due to drastic changes in the class hierarchy, e.g. an application implementing two disparate interfaces in the library, whose previously assigned obfuscated names then conflict. It's best to use -useuniqueclassmembernames when obfuscating the library to at least avoid these issues.

Otherwise, you should check whether the application project is configured properly; it should for instance have the original library as -injar or -libraryjar. Does ProGuard print out any notes or warnings?

[Renault Matthieu]

I'm not sure if -useuniqueclassmembernames should work well if i obfuscate in two passes like i want to achieve. Also i don't have any warning.

I join my tests:

• Library containing an functional interface
• Project implementing this functionnal interface

The configurations are just default (from the GUI) without shrinking and optimization.

The error i get

Exception in thread "main" java.lang.AbstractMethodError: my.project.MyProject$$Lambda$1/2003749087.a()V
        at my.project.MyProject.main(Unknown Source)

In the attachment zip i've added the non-obufscated jars, proguard conf, obfuscated jars and a run script.

Thanks, cordially
Matthieu

[Eric Lafortune]

Thanks for the sample project. In normal use, ProGuard preserves the names of methods of interfaces that are implemented in closures (in Obfuscator.java). This accounts for the somewhat unusual redundancy in the invokedynamic instruction. With the two subsequent obfuscation passes, the names of these interface methods are already obfuscated in the first step and only implemented in closures in the second step. I'll need to fix this by obfuscating the references in invokedynamic.

[Renault Matthieu]

Any news? We're currently stuck unless this issue is fixed (until the next ^^)