[Gdal-dev] [Fwd: [Geotools-devel] Google Summer Of Code]

[Norman Barker]

-----Original Message-----
From: gdal-dev-bounces at lists.maptools.org
[mailto:gdal-dev-bounces at lists.maptools.org] On Behalf Of Mateusz Loskot
Sent: Thursday, July 06, 2006 7:34 PM
To: gdal-dev at lists.maptools.org
Subject: Re: [Gdal-dev] [Fwd: [Geotools-devel] Google Summer Of Code]

Norman Barker wrote:
> Mateusz,
> 
> Can you keep me on the discussion about the Express Edition, I would
be
> interested in getting it working this way (though like Daniele I have
> also upgraded to the full version of VC++).
> 
> Tomorrow I will try to post some comments on JNI, SWIG and GDAL, as
> Daniele and Simone will confirm this is something I have been looking
> into as well.

Norman,

Sure, so let's continue discussion here, on the gdal-dev list.
OK?

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev

Thanks Mateusz,

Sorry I thought you suggested taking the previous discussion off list,
Visual C++ Express is actually quite good, and you can attach the
debugger to dlls which is perfect for Java JNI!

GDAL is stable and good software, and the SWIG binding does make it
accessible to Java, wrapping it behind ImageIO also makes sense (be
interested to see how you could make some of the creation options
available).

A typical java use case would be to use a GDAL dll in a servlet
environment (so GeoServer say), however the current implementation of
the Java classloader only allows one dll to be loaded for the whole JVM.
A single exception in GDAL or the underlying libraries in the c / c++
code will cause the JVM to exit and all users suffer :-). (do a google
on jni jvm crash)

A simple solution is to use the GDAL utility libraries and invoke them
in a separate process.  An alternative is to write a java client /
server socket scenario and invoke the server socket in a separate
process, this causes another JVM to start which is not ideal, but is
safe.

An ideal solution would be to implement a process manager in C++ as an
interface to GDAL and other libraries effectively making this JNI safe,
since this would have less overhead that starting up the JVM.

Just a couple of thoughts, quite happy to help on the SWIG / Java GDAL
development, just a bit snowed under for a couple of days.

Norman