Re: [Sablevm-developer] using a Soot-transformed classpath

[Grzegorz B. P. <ga...@de...>]

W li=B6cie z pon, 08-03-2004, godz. 15:07, Chris Pickett pisze:=20
> Clark VERBRUGGE wrote:
> >>is this a soot bug?  generating code for java.lang.Object that declar=
es=20
> >>java.lang.Object as a superclass?  or is there something particular t=
o=20
> >>what i'm doing that forces java.lang.Object as a superclass (i don't =
see=20
> >>it ...)
> >>
> >>i checked the jasmin disassembly of the transformed java.lang.Object=20
> >>classfile and it does indeed declare '.super java/lang/Object'
> >=20
> >=20
> > The super_class field of the classfile for java.lang.Object should be=
 0
> > (ie invalid constant-pool ref), so that sounds like a soot bug.
>=20
>=20
> Eric Bodden on the Soot list said it might be because two copies of=20
> java.lang.Object are in my classpath.  I tried the most minimal=20
> classpath I could find, and still had this problem.

> Can somebody else with sablevm-classpath installed verify this?  It=20
> takes less than 5 minutes.  I'm going a bit crazy with all these=20
> classpath issues.

I've just checked that with Kaffe's java compiler (KCJ) and Sun's
javac and they all dissasemble to this:

.source Object.java
.class  public java/lang/Object
; ACC_SUPER bit is set
.super  java/lang/Object

I imagine that by default, if there's no superclass, it's assumed to
be java/lang/Object, no matter what. I guess it might need a workaround
in Soot then.

HTH

					GBP

--=20
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM