[Soot-list] Handling conflicting class definitions?

[Patrick Lam]

On 05/01/13 17:56, Marc-André Laverdière-Papineau wrote:
> Hello,
>
> I have a bit of code I am trying to test that is using web services.
> Suppose that the WS implementation (non-abstract) class is pkg.Abc.
> The stub generated by wsgen is pkg.Abc too, but it is an interface.
>
> What happens in Soot is that only one SootClass is possible for any
> fully-qualified name. I sort of agree with that.
>
> The problem I get is that sometimes, the interface is returned by
> Soot.getSootClass when I want the implementation class.
>
> I wanted to know if there was a way to define an override to handle this
> kind of case, or if there was any way I could unload the interface and
> force resolving the implementation instead.
>
> I am guessing that there is no easy way to do that, but I'd like a few
> hints :)

There's the whole class loader thing where it is possible to have 
multiple classes with the same fully-qualified name. Soot probably ought 
to support some static approximation of a class loader, but it hasn't 
really come up as a problem for anyone. This might introduce quite a bit 
of additional complexity though.

pat