Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#131 Class member specification to allow !@... like !public, etc

open
Shrinking (1)
5
2012-12-17
2012-05-09
Anonymous
No

Would it be possible to allow !@annotation in the member specification, like !public et al, so that we can, for example, keep all APIs except those which have been deprecated for a particular JAR distribution.

Currently, the end-result can be acheive, painfully, by individually keeping each of the non-deprecated APIs, but that is highly error-prone. I have now once again (for about the 5th time) forgotten to add new APIs to my ProGuard config for a particular class which has about 30 deprecated APIs which are not included in one of it's two distributed builds.

For example, what I need is at least support for deprecation, but support for exclusion by any annotation would be better (and presumably neither here not there):

Instead of:

[code]
-keep public class com.... {
public protected <fields>;
public protected <init>(...);
static public <methods>;

# Message
public protected *** addLocales(...);
public protected *** contentToString(...);
public protected *** getName(...);
public protected *** isError(...);
public protected *** iterator(...);
public protected *** lock(...);
public protected *** nameEquals(...);
public protected *** setLocales(...);
public protected *** setMetadata(...);

# Structure (Must be the same as for MiStructure)
public protected *** addAll*(...);
public protected *** addField*(...);
public protected *** clear(...);
public protected *** containsField(...);
public protected *** dump(...);
public protected *** getField*(...);
public protected *** isLocked(...);
public protected *** isMessage(...);
public protected *** iterator(...);
public protected *** removeField(...);
public protected *** setAll*(...);
public protected *** setField*(...);
public protected *** toAppendable(...);
public protected *** toString(...);
}
-keep public class com.... {
public protected <fields>;
public protected <init>(...);
static public <methods>;

# Structure (Must be the same as for MiMessage)
public protected *** addAll*(...);
public protected *** addField*(...);
public protected *** clear(...);
public protected *** containsField(...);
public protected *** dump(...);
public protected *** getField*(...);
public protected *** isLocked(...);
public protected *** isMessage(...);
public protected *** iterator(...);
public protected *** removeField(...);
public protected *** setAll*(...);
public protected *** setField*(...);
public protected *** toAppendable(...);
public protected *** toString(...);
}

[/code]

I could have:

[code]
-keep public class com... { public protected !@Deprecated *; }
-keep public class com... { public protected !@Deprecated *; }
[/code]

Discussion


  • Anonymous
    2012-05-09

    On a side-note, is the current documentation wrong for the Class spec, in that annotations are shown twice, once non-negatable and the second time negatable:

    [@annotationtype] [[!]public|final|abstract|@ ...] [!]interface|class|enum classname

    [ -->@annotationtype<-- ] [[!]public|final|abstract| -->@<-- ...] [!]interface|class|enum classname

     
  • Eric Lafortune
    Eric Lafortune
    2012-05-11

    Thanks for the suggestion. Technically, it would be possible, but I'm not sure it's worth the effort (it's more complex than testing an access modifier). Configurations could also get confusing. Logically, I would then also have to add "!@deprecated" (generally, attributes of classes and class members) and "!implements" (implemented interfaces of classes). The only application I see is for removing deprecated classes and class members. I'll keep it in mind, but it won't get a high priority.

    The two @ characters in the specification serve different purposes: the first one is for matching an annotation on the class ("@SomeAnnotation public class SomeClass"), the second one is for matching a class that is an annotation itself ("@interface SomeAnnotation"). The second one is represented with an access modifier in bytecode.