[Geotools-devel] Avoiding Java Native Interface on GeoTools.

[johann s. <joh...@ge...>]

Hello,


We would like to start a discussion around JNI.

As you have seen in the past months some work has be done on GDAL.
This work is great and can be useful to handle more raster formats, but 
the problem is that GeoTools is getting tightly linked to those JNI 
classes.

It seem's that the approach choosed here to bind this work to GeoTools 
could introduce some problems in the future and it could be really 
useful to avoid tight dependency on it

- unnecessary jars for those who don't need the GDAL plugins.
- community work outside org.geotools package namespace
- community work on external svn
- additional barrier for GeoTools community to work on those modules


We ring the bell today because we have found that the render module has 
a dependency on an unsupported module which uses this JNI work
We feel concerned because render is in the library module, which means 
it is official and supported.
Besides, using JNI reduce geotools portability which is
the main purpose and the main reason why we use Java.

How can we solve this ?

Probably in moving JNI related classes outside GeoTools and keep it in 
it's native project ImageIO-Ext on java.net.
After all it is an extension that as be clearly envisioned as an 
independent  project, so it should not be part of geotools trunk.
Renderer should be designed in such a way that external projects
should be able to plugin extensions by overriding carefully designed 
methods.


We raise this issue because we are working as you know on a new Java2D 
renderer.
This one depends on the render module but not on imageio-ext. We believe 
there is a need to create
a render module independent so that multiple renderers may use it.


Regards

-- 
Johann Sorel

Company - Geomatys GIS Developer
Mail - joh...@ge...