I think it is relevant. That has been my most recent thinking process. I
am considering making the library cache the jmethodIDs based on classloader,
where they should be invariant (per classloader) (hmm, or should they?).
I'm trying to make classpath ridiculously robust. The question arises,
however, as to whether that is a desirable or secure thing to do. To use
different java.util.Vectors with possibly different implementations, does
that present a problem?
--John Keiser
> -----Original Message-----
> From: Bernd Kreimeier [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 24, 1998 5:28 AM
> To: Classpath
> Subject: Re: jnilink enhancements
>
>
> Maxim Kizub writes:
> > Just a few notes about class collecting and re-loading.
>
> I could add something else here. I tried to make my
> C++ classes for JVM/JClass/JObject fit for use with
> multiple JVM's from the same C application. As none
> of the field/methodID information etc. is supposed
> to be invariant between JVM's, and not even between
> JNIEnv's (different threads handled by the same JVM),
> this got pretty messy, too. Some information (values
> of constants, strings, signatures) is identical, other
> is not. I have yet to find an elegant solution, and
> I am not sure whether the (purely hypothetical) use
> of multiple JVM's from the same C app justifies the
> overhead.
>
> Well, that is probably not an issue for the java.*
> implementations in Classpath anyway. Or is it? As
> in using different class loaders, classes in different
> threads etc.?
>
>
>
>
> b.
>
>
>
