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 > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
