> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Stuart Ballard
>
> <Japhar removed from references as it really has nothing to do with
> them>
>
> I just took a quick look in EF's source tree (only at the names of the
> files, though) and it appears that they have all the classes needed for
> Classpath integration. I would guess that this integration will be at
> least as easy as Japhar was.
>
> The Throwable bit might be the hardest part, as it seems to be the only
> bit that doesn't map immediately to an existing part of the java.* API.
> Maybe the person doing the EF integration work, whoever that turns out
> to be, might work on making the changes to the integration API to get
> Throwable implemented by the VM.
>
Throwable I plan to move into the VM Integration API pretty soon.
gnu.vm.stack.* will go away. It's been on my plate for a while, but I
haven't gotten around to it. I'll see about it Wed. night, and make sure
everything still works (I believe it will work without any changes to
Japhar).
> John Keiser wrote:
> >
> > If we had the Classpath JavaDoc up, I could just link to those
> ... the API
> > requires that you implement certain *classes* and does not make any
> > assumptions about the methods you put in there except that they
> must conform
> > to the interface the rest of Classpath expects. All the names of those
> > classes are documented in
>
> I think the URL that John is referring to is
> http://www.classpath.org/docs/vmintegration.shtml
>
I should have been more specific. http://www.classpath.org/cvs/vm/reference
has all the *methods* that need to be implemented. vmintegration.shtml just
has class names.
> > The interface doc may be a little out of date after Aaron's
> changes. One of
> > us will check into that. The VM classes' interfaces, however, should be
> > precisely the same.
> >
> > I believe that's what he's saying. The way it was solved for
> Japhar was to
> > have separate libraries for lang, reflect, util, io, and net,
> and not load
> > util, io or net when running Classpath. That seemed to work fine.
>
> I may be misunderstanding, but if I understand right, this only applies
> if the JDK is being used as a fallback for areas that Classpath doesn't
> have. If so, the problem will go away by itself as Classpath approaches
> completion. Is that right or no?
>
Well, in the case of Japhar, they want to have the choice of both JDK and
Classpath--it is not mainly for technical reasons that they want this, as
far as I understand it. But yes, if you're only working with Classpath
these problems go away completely.
--John
