Re: resolveConcreteDispatch() and resolveAbstractDispatch()

[Ondrej Lhotak <olhotak@sable.mcgill.ca>]

On Fri, Apr 19, 2002 at 04:12:04PM +0100, Stephen Cheng wrote:
> My question is: if the superclass c implements a method of signature with a
> private attribute, doesn't this algorithm returns a false positive? It
> should throw a run-time exception but doesn't appear to do so.

Giving the private method as a possible target should be safe, because
it is may-call (rather than must-call) information that we are
reporting. Certainly we could remove the private methods to improve
precision, but then we would have to check whether the call site is in
the same class as the target.

A concern would be that a private method could mask a public method
declared in a superclass. This is definitely disallowed in the Java
language, but if I make it happen anyway in bytecode, you are correct
that the JVM skips over the private method and finds the public one.
However, I don't see the VM spec specify this anywhere. Also, I can't
imagine even a non-Java compiler ever producing such bytecode.

My question: how are you getting code with a private method overriding a
public one?

Summary: This situation cannot happen with code produced by javac. The
VM spec does not specify how it should be handled. Soot's assumptions
are different than those of the VM. Fixing it is slightly messy (when
you consider both private and package access).

An alternative solution would be to have Soot continue up the hierarchy
whenever it finds a non-public target to make sure that it is not hiding
a public target. If it is, then Soot would give an error saying that
this ambiguous situation has been encountered.

Is my reasoning correct?

Ondrej