Re: Starting JNI wrappers - a few questions

> 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?

You can use a PJ_CONTEXT created by one thread in another thread. The golden 
rule is not to use in more than one thread at the same time as you stated 
above.

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

Rather long lived. The PJ_CONTEXT caches the sqlite3 database handle, and even 
higher level objects. So createOperations() performance would suffer if you 
start from a new PJ_CONTEXT everytime.

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

There shouldn't be any problem to just exit the JVM without terminating PROJ. 
The sqlite3 handle is on a read-only file, and only read-only operations are 
done, so nothing to corrupt.

> 
> 
>     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?

UTF-8 is more or less implied. The EPSG database is ingested from a UTF-8 
dump. People could potentially try to ingest non UTF-8 strings in import from 
WKT, but we could/should just state in the documentation that all strings 
ingested are expected to be UTF-8 (in which case all strings output by PROJ 
will be UTF-8 as well)

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj