Perhaps it is just under Javas 5 that we have had trouble. Ben's
understanding seems sensible; I don't see a problem to start adding that to
new code developed for trunk.
Although I don't see the value in trying to take it on as technical debt (ie
a task to do to update existing code). We are already behind on technical
debt for the year with a lot of work from FunctionName being left to do for
gt-main.
Jody
On Tue, Jul 26, 2011 at 2:28 PM, Michael Bedward
<[email protected]>wrote:
> Like Ben, my preference would be to use the annotation, especially for
> the "dead code" protection which I find useful and much more reliable
> than my memory.
>
> Jody: did you mean that there are Java 6 compilers that don't handle
> the annotation on an interface method ? That would make them badly
> broken wouldn't it ?
>
> Michael
>
>
> On 26 July 2011 14:15, Ben Caradoc-Davies <[email protected]>
> wrote:
> > Java 6 @Override on an interface method is useful for detecting unpatched
> > implementations when a method is removed from an interface. Without this,
> > implementers will just be left with dead code.
> >
> > Another case where it is useful is interface extension that narrows a
> return
> > type, such as GeoAPI ComplexType.getBinding(), which overrides
> > PropertyType.getBinding() to narrow its return type from Class<?> to
> > Class<Collection<Property>>. Eclipse knows this is an override, and it
> says
> > so in the javadoc, but there is no annotation to force the compiler to
> check
> > that this really is an override.
> >
> > On 26/07/11 12:03, Jody Garnett wrote:
> >>
> >> No @Override on methods from an interface; they show up as errors on
> some
> >> compilers (depending on how you have things set up).
> >>
> >> @Overrides is an annotation designed to freak out when a super class
> >> changes (so you notice that it changes).
> >> Interfaces already have a compile error produced in this case (change
> the
> >> interface method and all children break until they are fixed).
> >>
> >> Jody
> >>
> >> On Tue, Jul 26, 2011 at 12:36 PM, Michael
> >> Bedward<[email protected]<mailto:[email protected]>>
> wrote:
> >> Hi folks,
> >>
> >> Just want to check on coding style following the move to Java 6.
> >>
> >> Should we always put an @Override annotation on methods implemented
> >> from an interface in new GeoTools code now ? And should we add the
> >> annotation to existing code ?
> >>
> >> Michael
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Magic Quadrant for Content-Aware Data Loss Prevention
> >> Research study explores the data loss prevention market. Includes
> in-depth
> >> analysis on the changes within the DLP market, and the criteria used to
> >> evaluate the strengths and weaknesses of these DLP solutions.
> >> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> >> _______________________________________________
> >> Geotools-devel mailing list
> >>
> >> [email protected]<mailto:
> [email protected]>
> >> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >>
> >>
> >
> > --
> > Ben Caradoc-Davies <[email protected]>
> > Software Engineering Team Leader
> > CSIRO Earth Science and Resource Engineering
> > Australian Resources Research Centre
> >
>
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
