> From: Paul Fisher [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > Jeez, multiple VMs are a friggin *nightmare* -- this whole class
> > caching issue is just one facet.
>
> native_state uses common practices that JavaSoft recommends for
> writing JNI code. If native_state doesn't work in a multi-VM
> environment, then the majority of JNI code out there will not.
>
Yes, that is true. I wasn't criticizing your code, actually, I think it's
great. But your statement is true: the majority of JNI code out there will
not work in a multi-VM situation.
> Does anyone know if JavaSoft is going to address this problem?
>
Likely they won't address the problem until they support multi-VMs
themselves, which doesn't seem to be coming along anytime soon. And even
when they do, it is literally impossible for current code to automagically
work in a multi-VM situation--it will have to be updated to whatever new
stuff they do :(
The only question we have to ask ourselves is whether *we* will support
multi-VMs. I suggest we decide that as early on as possible; otherwise,
it's going to be a rather annoying job to update everything later (there's
enough to update as it is). It is simple enough to make it conditional;
i.e. you can compile Classpath with or without multi-VM support. Most
people don't need it. JOS seems to want it, though I'm not yet sure why;
most likely it has to do with allowing multiple VMs of different version
running at the same time, since they don't support the idea of a heavyweight
process. No one else I know could think of a single reason to do it.
I would like to make a request, though: we really should find a way to use
Register and UnregisterNatives to load all Classpath methods, and not use
the standard names for them. This, at least, will allow us to be compatible
with multiple versions of Classpath in the same process.
--John Keiser
