[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Couple of issues


If you cd to your classpath and run
java soot.Main -d . java.lang.Object

Soot will gladly optimize java.lang.Object, and save it in the current directory (i.e. your classpath)
Now, when soot runs and needs to do something with java.lang.Object, it first looks in your classpath
and loads the .class file there, which is not the same as the SootClass object that you would get otherwise.

I've done this accidently by writing code which crawls the reachable classes and
makes them all application classes so their bytecode can be read. If (for instance)
a method invokes Object.getClass(), then java.lang.Object will be made an application class
and, if you have options for the output directory set to optimize "in place",
then you could get the behavior you describe.

I think soot out of the box doesn't use hasSuperclass() on the default arguments and so
this doesn't normally cause a problem.

Steve

At 04:32 PM 1/8/2004 -0600, Venkatesh Prasad Ranganath wrote: 
Stephen Andrew Neuendorffer wrote:
>
>>
>> 1> Scene.v().loadClassAndSupport("java.lang.Object").hasSuperclass()
>> returns true when one would think it should return false.
>> Is this a bug or a "feature"?
>
>
> I've seen things like that when java.lang.Object 'accidently' gets made
> an application class and saved in your classpath.
> then Soot doesn't recognize it as *the* java.lang.Object.

What do you mean by ".. and saved in your classpath"? I was under the impression Soot used the class files from the specified
class path and did not maintain any auxiliary paths. Or does it?

waiting for reply,

--

Venkatesh Prasad Ranganath,
Dept. Computing and Information Science,
Kansas State University, US.
web: http://www.cis.ksu.edu/~rvprasad