Generally I like the use of the annotation as it tells me when I screw up
but one thing to consider is maintaining both the trunk and 2.7.x. Having to
worry about removing such annotations when backporting makes it more work...
lead to more conflicts, etc... I wonder if it would be wise to wait until
the current trunk is the stable branch to adopt this.
On Tue, Jul 26, 2011 at 3:47 AM, Jody Garnett <[email protected]>wrote:
> 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
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
