Le vendredi 10 décembre 2010 15:22:25, Ivan Lucena a écrit : > Ciao Simone, Salut Even, > > Let's see this one here for example: > > Method names begin with Capital letters. The Java standard is > > that methods always begin with lowercase letters; classes begin > > with Upper Case letters. Constants should be all UPPER_CASE. > > > > Dataset hDataset = > > gdal.Open(filename,gdalconstConstants.GA_ReadOnly).GetDriver().getLongNa > > me(); > > > > should read > > > > Dataset hDataset = > > Gdal.open(filename,GdalconstConstants.GA_READONLY).getDriver().getLongNa > > me(); > > So what should we do?
You're talking about an hypothetical change, right ? Or I missed that one ;-) > > Prepare for change in GDAL 2.0 sound good to me. > > We can have two Java wrapper with a deprecated warning on the older > (maintain it for about a year or two) and the new one would complain with > Java standards and updated to whatever the language have evolved so far. You mean maintaining 2 versions of the bindings in the same branch, like we did for the old-gen and new-gen python bindings ? This causes much confusion for users, not mentionning the increased maintenance burden. So I'd prefer if we can avoid this. And IMHO GDAL 2.0 isn't necessary a justification to break API. It is more an opportunity. Luckily, there are still ways of making evolutions without breaking stuff ;-) > > IMHO. > > Regards, > > Ivan _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
