Re: Phantom classes and analysis

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

I think the main reason why Soot always requires java.lang.Cloneable is
that the Java VM Spec states (from section 10.7: Array Members):

  Every array implements the interfaces Cloneable and java.io.Serializable.

The type system therefore needs Cloneable in order to deal appropriately
with arrays. I believe it loads Cloneable even if there are no arrays
in the program, but there almost always are arrays anyway (think
public static void main( String args[] ) ).

One way to make it not require Cloneable and java.io.Serializable is to
set the isJ2ME flag in soot.Main to true. Apparently in J2ME, arrays
do not implement Cloneable and Serializable.

Ondrej

On Wed, Jan 22, 2003 at 11:01:57AM -0500, Patrick LAM wrote:
> On Wed, 22 Jan 2003, Eric Bodden wrote:
> 
> >     JimpleBody body  = (JimpleBody) method.retrieveActiveBody();
> > to get the body of the methods and then the line numbers of the single
> > units. So far ok. But now I have the problem, that when I do not include
> > the JRE into my classpath ("%javahome%\lib\rt.jar" to be precise), then
> > Soot crashes with an exception telling me that java.lang.Cloneable could
> > not be found. I mean: Of course it could not be found. But why is Soot
> > actually trying to resolve that deeply? I thought java.lang.Cloneable
> > would just be made a phantom class and then this would be ok. But it is
> > _not_ resolved as phantom class and so cannot be found. Why?
> 
> Things don't really work right if Cloneable isn't found; I'm sure that one
> of your classes implements Cloneable.  If we don't have a SootClass for
> java.lang.Cloneable, type inference usually won't work.  We don't like not
> having type inference, so we don't allow phantom refs to be arbitrarily
> created.
> 
> If you do what Feng said and hardcode allowPhantomRefs to true, then your
> classes should jimplify, but you won't get great things out of it.
> 
> pat
> 
>