Re: [gdal-dev] image-io extension

[Ivan Lucena]

Even,

>  -------Original Message-------
>  From: Even Rouault <even.rouault at mines-paris.org>
>  To: Ivan Lucena <ivan.lucena at pmldnet.com>
>  Cc: Simone Giannecchini <simone.giannecchini at geo-solutions.it>, gdal-dev at lists.osgeo.org, Viji V Nair 
<viji at fedoraproject.org>
>  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,