Take the 2-minute tour ×


        -injars     ${dist}/${jarname}

        -target 5

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

        -optimizationpasses 4
        -repackageclasses ''

        -keep public class * {
            public static void main(java.lang.String[]);


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*/ );


share|improve this question
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 8 '09 at 19:28
thanks, well the member is initialized in a function i call before accessing it. –  clamp Nov 8 '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 8 '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 8 '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 9 '09 at 13:01
add comment

2 Answers

up vote 2 down vote accepted

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.

share|improve this answer
add comment

According to http://stackoverflow.com/questions/93290/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?

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

Your Answer


