[Proj] New proposal of JNI bindings for Proj.4
Martin Desruisseaux
martin.desruisseaux at geomatys.fr
Thu Aug 25 20:05:54 EST 2011
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
More information about the Proj
mailing list