On Jun 12, Mark Wielaard wrote:
> Hi,
>
> I just looked at the differences between the java.util.zip implementation
> of libgcj with CNI and the version that Jochen Hoenicke made with JNI.
> <http://www.Informatik.Uni-Oldenburg.DE/~delwi/classpath/JCL/>
>
> Since I know nothing of CNI or JNI I will need to learn a bit more about it.
> But I thought that it might be a good idea to tell you my first impressions
> so people can correct me when I am wrong.
>
> CNI is readable and JNI is not. This might be because the Perl script that
> Jochen made inserts a bit more casts and JNI functions then necessary.
The JNI is really a bit unreadable. With the unnecessary casts you
probably mean jobject to jbytearray, which are all typedefed to the
same type in C. But for C++ they are necessary.
>
> With CNI a reference to gnu.gcj.RawData is used to hold data that the native
> code needs. With JNI a reference to a byte[] is used. It seems that a
> reference to RawData will not be touched by the Garbage collector. I am not
> sure why that is necessary in this case.
This depends on the garbage collector. Some garbage collector may
depend that all object fields point to real objects allocated with
NewObject. I think many JVMs enforce that. With the byte[] I'm
compatible but have a little bit more overhead.
Classpath also contains its own native state library (NSA), which uses
a hashtable to map objects' internal hashcode to data. This has other
disadvantages: It has more runtime overhead, since it has to lookup the
hashtable and there may only be one native state per object, so if the
super class already uses it, you can't use it.
> The CNI version does all Nullpointer and array bounds checking in native
> code. The JNI version does all that checking in java. I am not sure why
> you would want to do that checking in native code in this case.
> I like the JNI version more since that does all the sanity checking in
> a java wrapper and then hands of the checked data to the native code.
:-)
> The CNI version seems to synchronize all the native calls, the JNI version
> does not. That is how I interpret the first line of every CNI function:
> JvSynchronize sync (this);
I have removed the synchronization (though the perl script supports
it), since it is unnecessary. The De/Inflater is by design not thread
safe, since de/inflate and setInput are distinct functions. The
comment I put in the header of the java files documents this.
Jochen
