"John Keiser" <[EMAIL PROTECTED]> writes:
> > From: Brian Jones
> >
> > "John Keiser" <[EMAIL PROTECTED]> writes:
> >
> > > Right now we only support Japhar. But we want to support
> > multiple VMs.
> >
> > Yes.
> >
> > > The simplest way to do this is to provide two JAR files: one, the
> > > VM-independent stuff (everything not in vm/reference), and two, the
> > > VM-dependent stuff. This makes it so that we can support multiple VMs
> > > without too much trouble.
> >
> > Well, before providing a solution, perhaps backup and elucidate the
> > problem. Right now, supposing the --with-kaffe stuff worked (and we
> > had the kaffe dependent stuff coded) then to get Classpath to work
> > with Kaffe I would just reconfigure and recompile. (the native stuff
> > is different as well I guess...).
> >
> > If you wanted to argue that you want to be able to compile Classpath
> > for every VM all at once, I could see that.
> >
>
> The are two issues with that:
>
> 1. Why package two giant Classpath distributions for two different VMs when
> over 95% of the classes (probably more like 97-98% when all classes are in)
> will be identical in each distribution?
>
> 2. The VM should be able to package the VM interface classes *apart* from
> Classpath. We should not even have to know they are writing their VM for
> Classpath, they should just be able to plug in.
>
> Do we really want to provide a bunch of different distributions for
> different VMs, or do we just have one product with hooks people can plug in
> to?
Yeah, tis true. I just thought of the *real* issue, and that is that
all those "interfaces" for the VM specific functions should be clearly
defined and explicitly used by our source code. The class names of
implementations of those interfaces could also be forced to be the
same. Then we can really do one compile for distribution and the VM
stuff can painlessly be substituted for.
The issue of sealing remains, assuming it is required or even desired.
> Perhaps it's a pipe dream, but we don't know that yet. Rather than nix the
> idea altogether, we should try and brainstorm ways around the Sealing
> restriction. I think it's a goal worth achieving.
Awaiting ideas.
Brian
--
|-------------------------------|Software Engineer
|Brian Jones |[EMAIL PROTECTED]
|[EMAIL PROTECTED] |http://www.nortel.net
|http://www.classpath.org/ |------------------------------
