#21 interface methods get another names

[Martin Krivosik]

PROGUARD VERSION: 1.5.1

SHORT DESCRIPTION:

In some cases the interface methods get another names
during obfuscation process as the methods in the
implementation class (class
implementing this interface).

MORE DETAIL DESCRIPTION:

Let 'JobInfo' be the interface and the 'JobInfoV11',
'JobInfoV12', 'JobInfoV13' and 'JobInfoV14' the
classes implementing the interface. The 'JobInfoV14'
derives from 'JobInfoV13' which derives from 'JobInfoV12'
which derives from 'JobInfoV11'. The interface contains
method 'save'. This method is obfuscated as follows:

JobInfo save() -> dN_
JobInfoV11 save() -> dN_
JobInfoV12 save() -> dN_
JobInfoV13 save() -> save() <<< he is the problem
JobInfoV14 save() -> dN_

Because the method in class 'JobInfoV13' got another
name as the method in interfaces the following code
does not behave correctly:

JobInfo info = new JobInfoV13();
info.save();

It calls method save() from JobInfoV12 instead of
correct one from JobInfoV13. This is because after
obfuscation
the dN_ method is called. This method (dN_) does not
exist in JobInfoV13 and the JVM finds the "nearrest"
method in the
class hierarchy which is method from JobInfoV12. This
method is then executed.

ENVIRONMENT DESCRIPTION:

JDK 1.4.0
Over 3,000 java sources.

We do not keep knowingly 'JobInfoV13' class from
obfuscation process, but obviously its public methods
preserve the names.

QUESTION:

Is there any general workaround which can be used? Or
is it some known problem?
Of course, we can keep the whole 'JobInfo' hierarchy
from obfucation process, but this is not the solution,
because
there can be plenty of similar obfuscation problems
within the whole project.

Do you have any idea?

[Eric Lafortune]

Logged In: YES
user_id=555208

Thanks for your bug report.

It sounds a lot like the only bug I have bumped into
recently. It only happens under uncommon conditions and it
can be worked around.

Technically: ProGuard obfuscates class hierarchies one by
one, each time starting at a class that isn't subclassed. It
links names that should get the same name and then assigns
names. Sometimes, it processes a new hierarchy and comes
across a method that had been assigned a name already, while
the method also has a name in the new hierarchy. In order to
avoid conflicts, neither of the two names is used, and a
globally unique name (ending in '_') is used. If the second
name happens to be a name that the user wanted to keep, this
name is lost.

This problem only seems to occur when processing libraries
where public classes extend or implement non-public classes
or interfaces. This seems like a bad idea anyway, and
avoiding it should solve the problem.

Alternatively, as a work-around, you can specify to keep the
method name in the (non-public) top-level interface, so
ProGuard never gets confused.

Regarding your particular code: you say that you don't
knowingly keep the 'JobInfoV13' class from being obfuscated,
but that it obviously preserves its public methods. ProGuard
never keeps anything from being obfuscated, unless
instructed. Could perhaps send me your configuration file?
It's also important to know which classes and methods are
public or protected, and which are not.

I will try to solve this bug soon, although maybe not for
the impending release 1.6.