[EMAIL PROTECTED] writes:
> > > if (is_not_cached_for_current_vm(jID))
> > > update_jfieldID(jID);
> > >
> > Hmm, now that is an interesting and very good idea. Have to bring it up
> > with Japhar. Would bring them up to spec and make legacy code compatible
> > with multiple VMs ...
>
> I'm still unconvinced that this is what we want to do... I mean,
> there's really *no* reason that a person couldn't somehow (a rather
> pathological case, yes.) get japhar and the JDK running in the same
> process. yes, yes, I know. this is an edge case. but here's an
> example where fieldID caching across VM's just wouldn't make sense.
IMO this requirement is as undesirable as having classpath
interoperate with SMI JDK classes. Don't you get all the
drawbacks for trying to accomodate proprietary JDK?
> I think it's overly limitting (from a VM) standpoint - to support
> caching/sharing of ID's.
I think that either the VM's JNI provides the app with a
builtin caching mechanism that performs just as well as
your own app caching could possibly do, or you need to
support caching (shared or not). The performance penalty
is too big for some apps, IMO and all.
I think it is overly limiting (from a Japhar standpoint) to
guarantee a Japhar VM can be used with a JDK VM in the same
process. Do you want to guarantee that multiple JDK VM's can
be used in the same process, too? Maybe w/o Japhar?
If the verdict is to abandon multiple VM support as long as
not properly specified by Sun, I can understand that. If you
decide to support multiple VM's, you are already taking the
risk of your work being rendered obsolete by another of Sun's
jerky [sic!] moves. At that point, there is no point in trying
to accomodate JDK anymore.
b.
