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

[Martin Desruisseaux]

Hello all

In preparation for the GeoAPI session at the FOSS4G, I wish to provide a GeoAPI 
implementation on top of the C/C++ Proj.4 library as a "proof of concept" that 
GeoAPI can be used for accessing transparently existing libraries. JNI bindings 
already exist <http://svn.osgeo.org/metacrs/proj/trunk/proj/jniwrap/> in Proj.4, 
thanks to Andrea Antonello's work. However I wish to provide the bindings in a 
different way:

  * 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).
  * 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.


There is also some apparent memory leaks in the C side of current bindings that 
I would like to fix. In addition, I think that the binding code in C should also 
checks argument values (null pointer, index out of bounds) in order to avoid a 
crash if a Java application pass wrongs parameter values.

The Java API proposal can be viewed there. Every methods in this class are 
native methods:

  * http://www.geoapi.org/geoapi-proj4/apidocs/org/proj4/PJ.html


The C side of the JNI bindings (not including the old bindings):

  * https://geoapi.svn.sourceforge.net/svnroot/geoapi/trunk/geoapi-proj4/src/main/native/jniproj.c


So my questions are:

  *

    Do peoples agree to commit those new JNI bindings (without GeoAPI
    dependency) straight into the Proj.4 SVN code base, together with the
    existing bindings? There will be no change in the existing configuration
    that enable/disable compilation of JNI bindings.

  *

    What do we do with existing bindings?

      o Taking some time for fixing the memory leaks and add argument checks?
      o Or deprecate them, suggesting peoples to use the new JNI bindings instead?

I guess that the answer to my last question depends on how widely used are the 
current bindings?

In any case, I want to thanks Andrea Antonello since its current bindings 
provided a very convenient starting point that make very easy for me to try 
alternatives.

     Regards,

         Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20110825/986d7c5b/attachment.htm