#482 Signature attribute lost in some classes despite -keepattributes Signature

[Karsten]

I'm having some problems with proguard 4.10 dropping the Signature attribute of SOME classes even though -keepattributes Signature is specified in the configuration, causing problems with reflecting on generic type parameters at runtime.

I've tried versions 4.7, 4.8, 4.9, 4.10, and 4.11-beta-3 with identical configurations; the problem first appears in 4.9 (i.e. 4.7 and 4.8 correctly keep the Signature attribute).

The classes in question are kept via "-keep,allowobfuscation", however changing it to a vanilla "-keep" does not make a difference. Setting -dontoptimize does not make a difference.

The type hierarchy for the affected classes looks like this ('Foobar' being a placeholder for a largish number of different names that all use the same pattern of classes / interfaces):

abstract class FeedItem;
class FoobarFeedItem extends FeedItem;
abstract class FeedItemModel<T extends FeedItem>;
class FoobarFeedItemModel extends FeedItemModel<FoobarFeedItem> implements FoobarMeta;

It is some of these latter type of classes that are losing their Signature. Looking at the bytecode output in JClassLib, the Signature seems to be lost exactly in those cases where the FoobarMeta interface is optimized away.

Forcing the FoobarMeta interfaces to be kept with "-keep,allowobfuscation interface **Meta" seems to make the problem go away.

[Eric Lafortune]

Thanks for the detailed report. I can reproduce the problem. I'll see what I can do.

[Alexander Udalov]

We've met a similar problem in Kotlin where we use ProGuard to optimize the contents of kotlin-reflect.jar and generic signature is removed from several implementation classes, which makes it impossible to use Kotlin reflection on Graal VM: https://youtrack.jetbrains.com/issue/KT-23962. Apparently, Graal effectively loads generic signatures of all classes at the application start up and fails if some of them are incorrect. We use -keepattributes Signature in our config file but signatures are deleted nevertheless.

I see a motivation described in #604 as to avoid keeping classes which are mentioned in (seemingly unused) generic signatures but TBH I don't really buy it: I think there should be a way to force ProGuard to keep all signatures anyway, for example if my code is using Java reflection in a non-trivial way and I'm willing to sacrifice some bytes of the final application size, getting the correct behavior in return. Maybe this could be a completely another option, for example -keepsignatures.

BTW the workaround of keeping the class, mentioned in the description of this issue, is not very convenient in cases like ours as we'll have to locate all these classes first, and there's probably more than one. We'll do that anyway, but I imagine this problem could become more severe as other users try to run their ProGuard-optimized applications on Graal. Would appreciate a proper fix for this issue.

Thanks!