This is the mail archive of the
mailing list for the Java project.
Re: CNI namespace
Tom Tromey wrote:
> >>>>> "Cedric" == Cedric Berger <firstname.lastname@example.org> writes:
> Cedric> Ok, but then how will look the CNI functions if you want to
> Cedric> store Packet on a global native variable (or a queue, or
> Cedric> whatever), for example:
> We don't really know.
> Right now you can get away with doing this, if the global variable is
> in the data section, because the GC scans the data section.
I was also concerned by the fact that - if I understand correctly ?? -
Packet in my example would be a proxy class allocated by gcjh
somewhere on the stack and would become invalid as soon as send()
retruns to the VM.
> I doubt we want to rely on that long-term. Instead we'll probably add
> some sort of root-marking call you can make. Perhaps we can do this
> in such a way that the JNI mode will create a GlobalRef for you.
> Remember that Paul's approach is really only going to be used for JNI
> compatibility, where required. In general we'll still recommend using
> CNI with gcj. And, in fact, libgcj will continue to use it. The JNI
> compatibility will only be used when building Classpath against a
> non-gcj VM.
Yes, but I really like Paul's wrapper approach and I'm sure that if it
works well, I will also use gcjh outside of GCJ context, for programming
native methods for Sun's or IBM's VM, because the wrappers do
all the tedious job of retrieving objects ID, members, ...
Continue the good job!!
tel;fax:++1 (650) 574-4476
tel;work:++1 (650) 574-4472
org:Wireless Networks Inc
title:Embedded Software Engineer
adr;quoted-printable:;;2322 El Camino Real=0D=0A;San Mateo;CA;94403;USA