Optimization is performed even if disabled

2013-02-01
2014-09-16
  • Dmitry Katsubo

    Dmitry Katsubo - 2013-02-01

    It looks like I cannot get the real meaning of -dontoptimize option.

    I am running ProGuard 4.8 for all-in-one jar file with -dontobfuscate -dontoptimize options.

    What happens is that ProGuard is still removing methods and variables from classes. For example it reports:

    [proguard] Note: org.apache.commons.lang3.StringUtils$InitStripAccents accesses a field 'NFD' dynamically
    [proguard]       Maybe this is program field 'com.ibm.icu.text.Normalizer { com.ibm.icu.text.Normalizer$Mode NFD; }'
    [proguard]       Maybe this is library field 'java.text.Normalizer$Form { java.text.Normalizer$Form NFD; }'
    [proguard]       Maybe this is library field 'sun.text.normalizer.NormalizerBase { sun.text.normalizer.NormalizerBase$Mode NFD; }'
    

    and NFD field is gone.

    Also I have passed explicitly the following option -keep class org.apache.commons.logging.impl.Log4JLogger assuming that this class will be kept together with all its members, so it should be equivalent to -keep class org.apache.commons.logging.impl.Log4JLogger { *; }. However most methods are gone from this class and also gone from org.apache.commons.logging.Log interface.

    How to disable removing class members for all classes?

    Also I think ProGuard could automatically preserve all fields which it finds during reflection analysis. All produced warnings seem to be a good match, so why not to enable automatic recovery? Where are hundred warnings generated as this one:

    [proguard] Note: org.apache.commons.lang3.ObjectUtils accesses a method 'clone()' dynamically
    [proguard]       Maybe this is program method 'com.ibm.icu.impl.CharacterIteratorWrapper { java.lang.Object clone(); }'
    ...
    

    so would it be logical to keep (don't remove) these methods?

     
  • Eric Lafortune

    Eric Lafortune - 2013-02-01

    You should add -dontshrink if you don't want ProGuard to remove unused classes, fields, and methods.

    The part "{ *; }" is important if you want to preserve all fields and methods.

    The note about "clone()" indeed seems superfluous --I may look into that--, but for other methods such a note generally requires a decision (in the form of some configuration) from the developer.

    Eric

     
  • Jin Kwon

    Jin Kwon - 2014-09-05

    Hi, Eric. I just got the same Note with ProGuard 5.0. Did you take a look into that? So, Should I have to keep org.apache.commons.lang3.ObjectUtils#clone() or java.lang.Object#clone()? Thanks.

    Oh, I just realised that I should read the following indented lines.

    [proguard] Note: org.apache.commons.lang3.ObjectUtils accesses a method 'clone()' dynamically
    [proguard]       Maybe this is program method 'org.apache.commons.lang3.text.StrTokenizer { java.lang.Object clone(); }'
    [proguard]       Maybe this is library method ...
    

    So I have to make a decision for keeping those references classes and fields, right?

    I dug further and ObjectUtils' public static <T> T clone(final T obj) method finds and invokes java.lang.Object#clone().

     
    Last edit: Jin Kwon 2014-09-05
  • Eric Lafortune

    Eric Lafortune - 2014-09-16

    ProGuard will always preserve all clone() methods, since they override the method in java.lang.Object, so you can suppress the note:

    -dontnote org.apache.commons.lang3.ObjectUtils
    

    Eric

     

Log in to post a comment.