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

open
Shrinking (1)
5
2014-08-05
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

  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    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.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks