java ProGuard remove (shrink) unused classes

Let's say I have this Java app:

package com.site;

public class MyAppBase {}

package com.site.free;

import com.site.MyAppBase;

public class MyApp extends MyAppBase {}

package com.site.pro;

import com.site.MyAppBase;

public class MyApp extends MyAppBase {}

package com.site;

public class Edition
{

    public static final int     FREE    = 1;
    public static final int     PRO     = 2;

    private static final int    EDITION = PRO;

    public static boolean is(final int edition)
    {
        return (EDITION == edition);
    }
}

package com.site;

public class EditionFactory
{

    public static MyAppBase get_app()
    {
        MyAppBase ret = null;

        if (Edition.is(Edition.FREE))
            ret = new com.site.free.MyApp();
        else if (Edition.is(Edition.PRO))
            ret = new com.site.pro.MyApp();

        return ret;
    }
}

Now, any combination of ProGuard configuration I'm trying to get rid of the non-selected edition (in this case it's FREE) doesn't work.

By "getting rid of" I mean make the actual class disappear (as well from the calling code).

In other words, a call like this:

final MyAppBase app = EditionFactory.get_app();

.. is currently being translated to, after ProGuarding it, this:

if (a.a(1))
    localObject5 = new c(); // <<< FREE
else if (a.a(2))
    localObject5 = new d(); // <<< PRO

.. while I'd wish it to be translated to this:

localObject5 = new d(); // <<< PRO only in the code (as set at Edition.EDITION)

Bottom line is (besides the fact that ProGuard is GREAT!!), I can't seem to make it "see through" and understand that Edition.is() is a boolean function returning开发者_Go百科 a constant which makes it ok to remove some classes.

I've tried configurations like:

-keep,allowshrinking,allowoptimization public class * extends com.site.MyAppBase
-optimizationpasses 10

.. nothing works.

On the other hand, if I refer to Edition.EDITION and comparing it inlined (i.e without any "proxy" functions), the Java compiler (v1.6) detects it and remove the whole reference to the non-selected edition/class.

This results in that ProGuard removes/shrinks the unused class which is great.

The only issue here is about maintaining - I'd be happy to keep being able to use the EditionFactory style.

The optimization isn't performed because ProGuard decides not to inline the method Edition#is, so it then can't simplify the resulting series of instructions. The method is not inlined because it is not very short and it is also invoked more than once. You could work around the first criterion with this undocumented JVM option for ProGuard:

-Dmaximum.inlined.code.length=16

Alternatively, you could work around the second criterion, by making sure the method is only invoked once:

return Edition.is(Edition.FREE) ?
    new com.site.free.MyApp() :
    new com.site.pro.MyApp();

Alternatively, you could probably create short functions isFree() and isPro(), because they would return constants, which would be inlined.

It's a good practice to check the processed code if you're expecting some particular optimizations, because they are often subject to complex constraints.

Nice to hear that you like ProGuard.

It is because your method is(...) can take in more values than 1 and 2 only. It could be called elsewhere from the code with 3, 4, 6... Proguard cannot exclude that case.

The solution to your issue is to make Edition an enum. You would not need the is(...) method anymore and could rely on equals(...).