[Proj] New proposal of JNI bindings for Proj.4
EMiller at dfg.ca.gov
Thu Aug 25 18:19:26 EST 2011
>>> On 8/25/2011 at 2:59 PM, Martin Desruisseaux <martin.desruisseaux at geomatys.fr>
> * The current binding expects /x/, /y/ and optionally /z/ ordinate values
> be provided in 3 separated arrays, while GeoAPI - like Java2D API - expect
> single array with (/x/,/y/) or (/x/,/y/,/z/) tupples (note that the
> C/C++ API allows both forms).
Well, GeoAPI will have to translate then, I guess...
> * The current binding allocates and deallocates the PJ C/C++ structure
> implies parsing the Proj.4 parameters) everytime the pj_transform method
> invoked. I wish a slightly different cycle in which the PJ
> 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. The overhead of recreating the PJ* structures isn't very high.
> There is also some apparent memory leaks in the C side of current bindings
> I would like to fix. In addition, I think that the binding code in C should
> checks argument values (null pointer, index out of bounds) in order to avoid
> crash if a Java application pass wrongs parameter values.
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.
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.
Eric G. Miller
CA Dept. of Fish & Game
More information about the Proj