Actually, I need to amend that now to say "jnilink is useless in a
single-VM situation." In a multi-VM situation, it will be supremely useful,
even necessary to avoid seg faults. If your program is meant to be used
across multiple VMs in the same process (be they parallel or serial), then
you will need it or something like it.
Thus, Classpath needs it. The Japhar version for multiple VMs will do
some semi-wacky stuff.
I am considering adding a define, JAPHAR_MULTI_VM, to the list of
standard defines. Even in Japhar, multiple VMs is not the norm, it's just
possible. Standard Java programs will never use the capability and it will
slow things down for them if they do. So I propose that the directive be
required to be explicitly turned on.
And a per-ClassLoader cache may have to be turned on if I'm wrong in my
interpretation of FindClass.
--John Keiser
> -----Original Message-----
> From: Bernd Kreimeier [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, August 08, 1998 4:32 AM
> To: John Keiser
> Cc: Classpath
> Subject: jnilink uselessness
>
>
> John Keiser writes:
> > JNILINK is useless. Use it no longer.
>
> Well, I do not feel so bad know that I did not
> have the time (yet) to get into it...
>
>
> b.
>
>
>
>
