Tom Tromey wrote:
Blake> Would it not make integration easier if it were divided into
Blake> the Classpath jar/zip, and a Kaffe glue jar/zip? Jes askin'...
Perhaps one of the Kaffe maintainers can reply.
In Kaffe's CVS head, there is a small jar with just the couple of
modified VM interface
classes and a bunch of Kaffe-specific classes, that gets prepended to
the classpath glibj.zip
on the booclasspath.
We only modify a small subset of the VM interface classes, so that the
modified classes
'override' those in Classpath's glibj.zip. The actual 'surface' (i.e.
the classes a VM implementor
choses to override in the VM interface in order to provide different
implementations) between
Classpath and a VM using it, is likely to vary between VMs, as some VM
interface classes are
necessary to override for a functional implementation, while others are
a facultative choice,
for example to provide a more efficient implementation by delegating
some aspect of the
functionality to the VM. Note also that the facultative parts can become
mandatory if one's
working on a platform where using the provided generic C implementation
of some native
functionality is not an option, for example.
In this case, I assume you mean dividing Classpath's glibj.zip into
separate vm-interface.jar
and rt.jar files, and delivering the two jars as part of Classpath?
Whether that Kaffe specific VM interface jar gets prepended to a single
glibj.zip file, or
two of them is not much of a difference, I guess. But I'm not sure I've
seen the benefit of
having a separate glue JAR laid out.
Could you elaborate some more on your idea?
cheers,
dalibor topic
