#439 Mapping is not consistent across java versions


We have a mapping file that is used to preserve the mapping from one build to the next, which is checked into our source control.

Recently we found that one of our developers was getting a "Warning :method is not being kept, but is being remapped".

From investigating this, the original build was done with java 1.6.0_29.
This particular developer was using java 1.6.0_24.

I have taken the build tree and have reproduced this warning, i.e. checking out the build tree, along with the mapping, and build this with 0_29 doesn't generate this warning. However taking this build and just swapping to 0_24, generate this warning.

So it appears that using a mapping file with different versions of the jdk can causes mapping conflicts (well at least warnings), although the code that is being built and the map file are unchanged.

Note this was happening with both v4.6 and v4.7.


  • Eric Lafortune

    Eric Lafortune - 2012-02-22

    Does the warning make sense in your application? Is the method name indeed being kept (with -keep in the configuration)? At the same time, is the method being mapped to a different name in the mapping file?

    I can't imagine right away what might be happening. If you can provide a small test case, I'll look into it.

  • Eric Lafortune

    Eric Lafortune - 2012-02-22
    • assigned_to: nobody --> lafortune
  • Darin DeForest

    Darin DeForest - 2012-02-22

    I don't believe there is a -keep to preserve this method.

    With the first build, using java 0_29, looking in the updated mapping file, shows that this method is being obfucated to eF and no warning is being generated. Then rebuilding this again with 0_29 doesn't generate any warning.

    Then I switch the java compiler to 0_24, and using the map files generated from the above step, this warning is generated, so in this case, proguard acts like the field shouldn't be mapped to eF, although the --keeps have not changed.

    In this particular case the method is called getPort. The class itself inherits from 2 internal interfaces which are only used for defining constants. Searching though the entire project, only this class defines getPort (although it used in elsewhere).

    So I'm a bit stumped why this is?

  • Eric Lafortune

    Eric Lafortune - 2012-02-25
    • status: open --> open-later
  • Eric Lafortune

    Eric Lafortune - 2012-02-25

    You're probably specifying -useuniqueclassmembernames. That's useful to avoid future naming conflicts, but ProGuard then tries to keep names globally consistent. With 0_24, it is picking up setPort from some library class and tries to preserve the name in the program class. Incremental obfuscation can only work reliably if the underlying libraries remain constant. I'll document this more clearly, but I can't spend more time on this now. In this case, you can ignore the warning.


Log in to post a comment.