[PROJ] Starting JNI wrappers - a few questions

[Martin Desruisseaux]

Hello all

I'm starting the development of Java Native Interface (JNI) for PROJ on 
a separated GitHub repository [1], with completion date targeted for 
December. We have chosen to use the C++ API instead than the C API, even 
if the C API may be more stable, for the following reasons:

  * Straightforward mapping to ISO 19111 objects. The C API in
    comparison uses a conceptual model which is particular to PROJ.
  * It seems possible to wrap the C++ objects into classical PJ
    structures using the PJ.iso_obj field, but it seems to impose a
    significant overhead (e.g. the process of wrapping an ISO 19111
    object into a PJ involves formatting the object in a PROJ string and
    parsing it in PJ).
  * Many (not all) C++ objects are immutable, which make easier to be
    thread-safe.

I have a first series of questions in order to help me to make some 
design choices. Can anyone gives some tips on the following?


    PJ_CONTEXT

I understand that a given PJ_CONTEXT can be used by only one thread at a 
time. But after a thread has (at least temporarily) finished to use a 
PJ_CONTEXT, can that PJ_CONTEXT be given to another thread (making sure 
that no other thread uses it in same time), or is it preferable to 
restrict the use of a PJ_CONTEXT to the thread that created it?

Are PJ_CONTEXT expected to be short lived (extreme case: a 
create/destroy cycle in a each JNI call), long lived (e.g. the whole 
lifetime of a Java Virtual Machine), or something between the two (e.g. 
I could setup a pool of PJ_CONTEXT which automatically destroys 
instances that were unused for more than 2 minutes)? I guess the answer 
depends on the cost of PJ_CONTEXT create/destroy cycles compared to the 
cost of holding them a long time.

Above questions are because I wish to avoid exposing PJ_CONTEXT in Java 
API, and instead have them managed automatically.


    Disposal at shutdown time

What is the consequence if an application using PROJ exits without 
destroying all PROJ objects? Is there a risk that PROJ leaves some files 
(e.g. related to the use of SQLite) in a locked or corrupted state? I 
ask because by default, Java does not wait for all objects to be garbage 
collected when an application terminates. If we need to ensure that all 
PROJ objects are properly destroyed at exit time, then I need to 
register a shutdown hook for them (not a difficult task - I'm just 
checking if it is necessary).


    Encoding of std::string

The C++ API has many methods expecting or returning a std::string 
object. In my reading of C++ specification, std::string seems to be 
encoding agnostic. Does PROJ makes any assumption on the encoding of 
std::string instances? Is it okay to unconditionally use UTF-8 
regardless the platform encoding when using std::string with PROJ API? 
Or should I unconditionally convert UTF-8 to platform encoding before to 
build a std::string?

     Thanks,

         Martin

[1] https://github.com/Kortforsyningen/PROJ-JNI

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190925/c8dd8883/attachment.html>