Re: old to new soot questions

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

The thing that changed is the connecting between RefType and SootClass.
These two classes represent similar things: a type that is a class.
In earlier versions of Soot, the RefType had no real connection to a
specific SootClass. However, for most type manipulation, a SootClass is
needed, because, among other things, it knows what the supertypes are.
So, we often convert between a RefType and SootClass. Previously, this
was done by querying the Scene for a RefType or SootClass with a
specific name, but this was changed to have the RefType have a pointer
to its SootClass and the SootClass have a pointer to its RefType.
Sometimes I think the two should be merged into a single class, but I
think I would encounter some opposition to that.

Anyway, when a SootClass is constructed in the current code, it
constructs a RefType for itself, and the RefType registers itself with
the Scene. Having two different classes for the same RefType can pose
all sorts of strange problems because the two are so closely related.
So, if you want to be able to have multiple SootClasses for the same
class, I would like you to suggest ways to handle the mappings between
class name, SootClass, and RefType.

One alternative that you might consider, which may be simpler, is to not
create new stub SootClasses for the classes that you are turning into
stubs. Instead, you could replace the methods and fields of the existing
SootClass object.

Ondrej


On Mon, Aug 11, 2003 at 03:12:42PM -0500, Oksana I Tkachuk wrote:
> Ondrej,
> 
> My application walks over the code of user supplied classes (let's call
> them U) and identifies all of the external references. Suppose, we
> identified external class E that is referenced by U. My program creates a
> stub for E and stores it in some table. Later, the program runs some
> analysis on real E, and generates code for stub E based on the analysis
> for real E.
> 
> Here is a feature that came up in new version of soot: when I create a
> stub via command
> 
> SootClass stubE = new SootClass(realEname);
> 
> this command seems to overwrite the real class E, so that later when I try
> to retrieve the real E from Scene, it gives me the stub, that of course
> doesn't have the real code.
> 
> I can easily fix the problem by giving the stub classes names that are
> different from the real names, but I was wondering why this change was
> made. The old soot didn't seem to mind me creating classes with the same
> names as long as I kept them out of Scene.
> 
> Oksana.
> 
> 
>