[gdal-dev] image-io extension

[Even Rouault]

Le vendredi 10 décembre 2010 10:27:49, Simone Giannecchini a écrit :
> Ciao Even,
> I have asked daniele to make those changes (which have not been reviewed
> yet) in order to move away from the explicit usage of Vector and HashTable
> in method signatures in favour of using the respective interfaces (List
> and Map). Daniele can add more as needed...

Simone,

I can understand that you don't like using Vector or Hashtable in the API you 
expose in imageio-ext, but you can also understand that it doesn't make a very 
compelling reason to take your changes in the hope that they also fit the needs 
of other users of the GDAL Java bindings. 

You could certainly convert the Vector into an ArrayList on your side and 
"hide" that. Not ideal, but there's no technical obstacle.

The GDAL Python bindings are also well-known for not being very "pythonish" by 
some aspects (and some of those aspects can be sometimes very very painful !), 
but it doesn't prevent them from being used successfully by a pretty 
impressive amount of people.

> 
> As you mentioned this change can break old code, but it should
> make the java bindings more ... javaish :).

I'd note that what is "javaish" or not is subject to trends that evolve over 
time. Sometimes it is not bad to wait for the dust to settle ;-)

And concerning :

> On the other hand GDAL is well known for the rock solid stability of
> its API

Indeed, I prefer that the bindings are stable (and sometimes expose rough 
corners due to past choices). Being "javaish" isn't an aim per se.

> but yeah this "instability" would apply only to the Java
> bindings and would follow a well known practice. """

I respectfully disagree with you on this. For example, most API of the 
standard Java library dating back to the Java 1.0 era haven't been removed in 
Java 1.6. And by the way, neither 
http://download.oracle.com/javase/6/docs/api/java/util/Vector.html nor 
http://download.oracle.com/javase/6/docs/api/java/util/Hashtable.html mention 
those 2 to be deprecated at all ;-) 
Now, you'll certainly find other Java projects that might have different habits 
of course.

Let's be realistic : interface breakage can happen sometimes. But IMHO the 
reasons must be very compelling (totally broken/unusable interface). And I'd 
expect a consensus on this, or at least support from a majority of users.

> 
> We have other changes in the queue which we might submit to your review
> early next year, but this is another topic...

If you wish that your changes to be integrated back into GDAL, I'm afraid this 
isn't the best way to proceed. It is not very efficient and enjoyable to review 
a code dump without prior discussion about its rationale and main orientations 
(especially when it involves API breakage). Basically, I'm just recalling a 
best-practice for collaboration with any FOSS project...

> 
> 
> Viji , I don't think you need to use the patch you are referring to since
> that is needed for imageio-ext 1.1 which has not been released yet.

I'm afraid that the packagers of imageio-ext 1.1 will face difficult 
alternatives if your patch is still needed but not applied in upstream GDAL :
- Applying your patch and thus forking from upstream GDAL as far as the GDAL 
Java API is concerned ? --> Most Linux distro (including Fedora unless I'm 
wrong) have a policy to stick to upstream as much as possible and only patch 
for serious reasons.
- Applying a patch to imageio-ext to make it work with upstream GDAL ? 
Unlikely for the same reason as above and why would they make that effort 
instead of upstream imageio-ext ?
- Finding a way to have a specific version of the patched GDAL Java bindings 
only used by imageio-ext ? Technically possible I guess by "duplicating" the 
java bindings (both the gdal.jar + the *jni.so) and embedding a specific 
version in imageio-ext package. But then, you will have to make sure they 
won't conflict in case someone wants to use both imageio-ext and "official" GDAL 
java bindings. I also doubt that a packager would want to go into that.


Best regards,

Even

> 
> Ciao,
> Simone.
> -------------------------------------------------------
> Ing. Simone Giannecchini
> GeoSolutions S.A.S.
> Founder
> 
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> 
> phone: +39 0584962313
> fax:      +39 0584962313
> mob:    +39 333 8128928
> 
> 
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.linkedin.com/in/simonegiannecchini
> http://twitter.com/simogeo
>