Even, > -------Original Message------- > From: Even Rouault <[email protected]> > To: Ivan Lucena <[email protected]> > Cc: Simone Giannecchini <[email protected]>, > [email protected], Viji V Nair <[email protected]> > Subject: Re: [gdal-dev] image-io extension > Sent: Dec 10 '10 18:41 > > 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 ;-) >
Well, you missed that part: "Now we find users asking for changes that are not essential and that break backward compatibility. Let's see this one here for example:". So, yes. It is "hypothetical" as you said. I am just passing on a suggestion from a user. If you are going do radical changes on the GDAL Java wrapper for the next release you could also take those issue in consideration, although there are "not essential". > > > > 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. I will follow your arguments on your reply to Simone to get more information. > 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 ;-) That is nice to read that. Regards, Ivan, _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
