<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.
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
> 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?
Stuart.
