java proguard: library doesnt work after optimization

Question

i am optimizing a jar with proguard, but it crashes after optimization. here is my proguard task:

    <proguard>
        -injars     ${dist}/${jarname}
        -outjars    ${dist}-proguard/${jarname}

        -target 5

        -libraryjars '${java.home}/lib/rt.jar'

        -dontobfuscate            
        -optimizationpasses 4
        -overloadaggressively
        -repackageclasses ''
        -allowaccessmodification

        -keep public class * {
            public static void main(java.lang.String[]);
        }
    </proguard>

as soon as i put in the -dontoptimize option, it works.

according to the stack of the exception it crashes when accessing a static public member of a class with a nullpointer. here is the code:

public static Texture ring, dust, spikering, thinring, crystal, clouds;

public static void init() {
    Field [] fields = TexturePool.class.getDeclaredFields();

    for (Field field : fields) {
        if(field.getType() == Texture.class) {
            field.set( null, /*imagine new object here*/ );
        }
    }
}

thanks!

I can't really believe that accessing (retrieving, or do you mean something else) the member will throw a NullPointerException. Do you mean that the member can be accessed, but is itself null, so that a NullPointerException is thrown, when trying to use the member? If so, where is the expected value coming from? — jarnbjo, Nov 08 '09 at 19:28
thanks, well the member is initialized in a function i call before accessing it. — clamp, Nov 08 '09 at 20:17
I asked about it, but why don't you care to tell us what _exactly_ goes wrong? What is the cause of the NullPointerException? Some VM-internal error when accessing the member (as your post seem to imply) or simply that the member is null, so that a NullPointerException is thrown, when you try to access the member instance? — jarnbjo, Nov 08 '09 at 21:48
This is a great example why obfuscators should normally not be used unless you REALLY have a good reason to. You basically need to retest your application as you have no idea what has been done to the poor bytecode that the compiler produced. — Thorbjørn Ravn Andersen, Nov 08 '09 at 23:18
@jarnbjo: ok i will try to provide a testcase. @thorbjorn: i agree, still i would be very interested as why proguards optimization leads to a crash — clamp, Nov 09 '09 at 13:01

score 2 · Accepted Answer · answered Nov 09 '09 at 15:32

ok, i just found out myself. i think the optimization completely optimized that classmembers away, since they are not directly accessed in this class. if i specify the option:

        -keepclassmembers public class com.package.** {
            public static * ;
        }

it works even with optimization.

score 1 · Answer 2 · edited May 23 '17 at 12:19

1

According to Best Java Obfuscation Application For Size Reduction:

"I was always able to fix the problem by not using the Proguard argument "-overloadaggressively"."

Perhaps you should try the same?

EDIT: The problem could easily be that an assignment is optimized away. The initializations happening in the source code, where a field is defined, is actually done by the compiler in a static code blokc. Appears that the optimizations tinker with that. What happens with fewer optimization passes?

edited May 23 '17 at 12:19

Community

1
1

answered Nov 08 '09 at 23:19

Thorbjørn Ravn Andersen

73,784
33
194
347

thanks, but even if i dont put the overloadaggressively option, i get the same crash. – clamp Nov 09 '09 at 11:23
Lovely. Time to tweak options one at a time. You _must_ obfuscate? – Thorbjørn Ravn Andersen Nov 09 '09 at 11:44
thanks! well, only when i specify 0 optimization passes, it works: -optimizationpasses 0 – clamp Nov 09 '09 at 12:58
@Thorbjorn: it is not obfuscation, but optimization (in proguard there is a difference!) – clamp Nov 09 '09 at 12:59
matt, I read the snippet wrong, and as "--obfuscate" where you had the opposite. – Thorbjørn Ravn Andersen Nov 09 '09 at 13:53

score 0 · Answer 3 · answered Nov 21 '14 at 20:27

I had the same issue with ProGuard optimizing away class fields that were modified using reflection API only. However, the suggested answer didn't work for me as there were too many classes scattered throughout the code base to specify class filter.

Instead, disabling field optimization did the trick for me:

-optimizations !field/*

java proguard: library doesnt work after optimization

3 Answers3