#380 -overloadaggressively and Class.get[Declared]Field trouble

v4.5
open-later
None
3
2010-11-02
2010-10-24
Joel Dice
No

Consider the following case:

$ cat > OverloadAggressively.java <<EOF
public class OverloadAggressively {
public String foo;
public int bar;

public String getFoo() {
return foo;
}

public void setFoo(String foo) {
this.foo = foo;
}

public static void main(String[] args) throws Exception {
System.out.println
(OverloadAggressively.class.getDeclaredField
("bar").getType().getName());
}
}
EOF
$ mkdir stage1
$ javac -d stage1 OverloadAggressively.java
$ java -jar proguard4.5.1/lib/proguard.jar -injars stage1 -outjars stage2 -libraryjars /usr/local/java/jre/lib/rt.jar -overloadaggressively -keep public class OverloadAggressively \{ public static void 'main(java.lang.String[]);' public void 'setFoo(java.lang.String);' public java.lang.String 'getFoo();' \}
ProGuard, version 4.5.1
Reading program directory [/home/dicej/p/misc/stage1]
Reading library jar [/usr/lib/jvm/java-6-openjdk/jre/lib/rt.jar]
Preparing output directory [/home/dicej/p/misc/stage2]
Copying resources from program directory [/home/dicej/p/misc/stage1]
$ java -cp stage1 OverloadAggressively
int
$ java -cp stage2 OverloadAggressively
java.lang.String

As you can see ProGuard is smart enough to update the string constant argument to Class.getDeclaredField when it obfuscates the name of OverloadAggressively.bar, but it fails to notice that there are now two fields with that name due to aggressive overloading, and we get the first (and wrong) one when running the obfuscated class.

A warning would be nice in such a case. Better yet: suppress aggressive overloading for fields known to be accessed via reflection.

Discussion

  • Eric Lafortune
    Eric Lafortune
    2010-11-02

    • assigned_to: nobody --> lafortune
    • priority: 5 --> 3
    • status: open --> open-later
     
  • Eric Lafortune
    Eric Lafortune
    2010-11-02

    I could print out an additional warning if ProGuard detects such a combination. Suppressing it for the fields involved doesn't seem worth the non-trivial effort. As a general rule, you just shouldn't use aggressive overloading in the presence of reflection.