[Proj] New proposal of JNI bindings for Proj.4

[Martin Desruisseaux]

Hello Eric

Le 26/08/11 01:19, Eric Miller a écrit :
>>    * The current binding expects x,y and optionally z ordinate values to
>>      be provided in 3 separated arrays, while GeoAPI - like Java2D API - expect a
>>      single array with (x,y) or (x,y,z) tupples (note that the Proj.4
>>      C/C++ API allows both forms).
>>
>> Well, GeoAPI will have to translate then, I guess...
Actually, we just need to invoke pj_transform(...) with the x=array, y=array+1, 
z=array+2 and point_offset=3. There is no need to copy any coordinate values.

>>    * The current binding allocates and deallocates the PJ C/C++ structure (which
>>      implies parsing the Proj.4 parameters) everytime the pj_transform method is
>>      invoked. I wish a slightly different cycle in which the PJ C/C++structure
>>      can be allocated once, reused for many calls to pj_transform, and
>>      deallocated when the Java peer is garbage-collected.
> When I wrote a .Net wrapper, I created a class that manages the lifetimes of the native PJ* resources and provided simple coordinate transform methods.  So, you could call the transform as many times as you want.  It implemented the .Net IDisposable interface for resource cleanup.  I don't know if Java has anything similar.  You can wait 'til garbage collection, but that can be awhile.
Yes, Java also have something similar. The reason why I choose to not put a 
dispose() method in that class is because typical GIS applications have a few 
Coordinate Reference System (CRS) objects shared by thousands of geometries (or 
rasters, etc.).  It can be difficult to determine when a CRS can be disposed, 
and doing it wrong can be dangerous. The users would need to ensure that the CRS 
is not used anymore by any other object... which is precisely the garbage 
collector job.

For applications dealing with only a few CRS, I think that the delay before PJ 
objects are garbage-collected will have unoticeable effect.

> In my experience, the thread resource issues with files and grids was the biggest issue.  If you can find memory leaks, they should be reported and fixed.
The memory leaks were in the JNI bindings. I don't think that the C library 
itself was impacted. This leak was occurring every time the pj_transform method 
was invoked though JNI, which may occur often.


> I had a good laugh about the C code doing array bounds checking.  Really, if you're wrapping a native library, you should be doing some argument validation before passing it along.
This is true that array bound checkings is not part of C/C++ tradition. However 
the JNI bindings are just a facade for Java applications - ignored by C/C++ 
applications -, and array bound checkings are part of Java tradition. As a rule, 
it should be impossible (in theory) for a user to crash the Java Virtual Machine 
even if he misuses a method. The fact that the method is native rather than pure 
Java is invisible from an API point of view (this details does not appear in the 
generated javadoc), so the user expects those methods to behave like any 
ordinary Java method.

Regards,

     Martin