[kaffe] verifyMode, obsolete flags, a man page patch, and trusted code

[Rob Gonzalez]

Hey all,

> I'd say it should do as jdk 1.2 does, and skip classes loaded from the
> bootclasspath, unless explicitely requested to verify everything. you could use
> CodeSource attribute of a class to see where it was loaded from, or check if
> its class loader is the primordial classloader.

The jdk 1.2 has three forms of bytecode verification.  The first two are
to verify everything or to verify nothing at all.

The last (and default) is to "only verify things loaded over a network".  
Like many things in Sun's verifier documentation, this isn't actually how
it behaves.  In fact, when you use the option "Xverify:remote" it verifies
everything not in the default bootclasspath, regardless of whether it was
loaded "over a network", which is as Dalibor suspected.  Grrrrr Sun.  
Anyway, I've included another patch here that includes -verifyremote
documentation in the man page for kaffe.

Now, in order to implement this behavior we not only have to check that
the classloader is the primordial classloader (which i *think* is
trivial...just check whether class->loader == NULL) but also that the file
retrieved is from the bootclasspath, and not simply the classpath, as the
primordial class loader loads from both.  My current idea is to have the
primordial class loader mark the classes loaded from the bootclasspath by
setting a "trusted" flag...but I'm having trouble figuring out where
exactly it is determined whether a class comes from the bootclasspath or
from the classpath.

Question: In libraries/javalib/kaffe/lang/PrimordialClassLoader.java, am I
right in saying that findResources() searches only the bootclasspath and
not the classpath?  If that's the case, I think it makes the above idea
relatively easy to implement (though, at this point, I haven't messed
around with where exactly to mark the class as trusted, so I'm not sure
how easy it's going to be to propagate that information through the method
calls to where the actual Class object is allocated in memory).

If anyone can think of a simpler way to do this without modifying the
PrimordialClassLoader, give a shoutout :)


As a quick aside, do we plan on moving kaffe's execution options over to
the jdk 1.2 format at some point (i.e. do we want people to use kaffe from
the command line just as if it were Sun's JVM)?  For instance, instead of
-verify or -verfyremote, which are the Java 1.1 options accepted by Sun's
JVM and by kaffe at this point, Java 1.2 uses -Xverify:all and
-Xverify:remote, where the 'X' preceding the option means that the option
is "non-standard and subject to change without notice" (in the 1.4
release, the -Xverify option is not documented at all, though it is still
processed by the Sun JVM).


Cheers,
Rob