[PROJ] Motion: Accept RFC4 (PROJ JNI Overhaul)

[Howard Butler]

I'm -0 for the same reasons as Even states. If the Java bindings weren't already in PROJ for 15 years, I would be vetoing, but the ship has sailed. The updated Java bindings should be architected in such a way that if they stale again in 5-10 years that they can be ejected out of the tree into their own repository.

I am not supportive of any other language bindings coming into the PROJ source tree. We do not want to bless any bindings as official because this is likely to squash any innovation that might go on. This action also has a bad side effect of tying the release of the bindings to the release of the main library, which may or may not be a good idea. These things are separate and should evolve and be maintained separately. 

Howard

> On Jul 17, 2019, at 4:15 AM, Even Rouault <even.rouault at spatialys.com> wrote:
> 
> Hi,
> 
> I vote +0
> 
> - I'm supportive of having rejuvenated Java bindings.
> - I won't likely be a user / contributor to them myself.
> - I've some doubts that having them in OSGeo/PROJ repo is the best thing, but 
> as the RFC mentions the use of only public PROJ C or C++ API, it could be 
> possible to exfiltrate them if needed.
> 
> Ah, the RFC doesn't mention licensing consideration. I assume the code will be 
> under the PROJ X/MIT license ? At least, the native part, especially if it is 
> bundled into libproj.
> 
> Other nitpicking detail. The RFC currently mentions: "The PROJ Java Native 
> Interface exposes the ``proj_api.h`". This is not actually true. src/
> jniproj.cpp includes proj_internal.h and uses functions that were part of 
> former projects.h
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj