Proposal for CNI/JNI problems

Jon Olson olson@mmsi.com
Sat Apr 1 00:00:00 GMT 2000


On 2000年1月12日, Jochen Hoenicke wrote:
>Another point is how to put pointers to native structures into a
>classfile. Sun didn't solve it well. If I understand the code in
>japhar's java/util/zip correctly sun used an int field to store the
>pointer and later changed it to long to support 64bit architectures.
>libgcj declares natives fields as "gnu.gcj.RawData", but this is not
>portable to other jvms, where the garbage collector doesn't know that
>this class is special. My solution was to put the structure into a
>java byte array, which imposes a little overhead, but should be
>portable (and you get it freed automatically).
>> Jochen

Interesting idea, putting the native peer class into a byte array.
Seems like kind of a hack, but I guess it solves the problem.
Sun's solution of using a long to store a pointer is a real kludge.
My solution was to store an `int' as the peer and to make any
Java class which require a native peer a subclass of this Peer
class:
public class Peer
{
 protected int _peer;
 public Peer(int peer)	{ _peer = peer; }
 public native void destroy();
 protected void finalize() {
 destroy();
 }
}
Native code stores peer objects in a C++ Vector and manages
recovering space when finalized in destroy().
-- 
Jon Olson, Modular Mining Systems
	 3289 E. Hemisphere Loop
	 Tucson, AZ 85706
INTERNET: olson@mmsi.com
PHONE: (520)746-9127
FAX: (520)889-5790


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /