commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [CLI] fixing warnings
Date Thu, 21 Apr 2011 12:51:34 GMT
On Thu, Apr 21, 2011 at 8:03 AM, sebb <sebbaz@gmail.com> wrote:

> On 21 April 2011 11:59, Emmanuel Bourg <ebourg@apache.org> wrote:
> > Le 21/04/2011 10:21, Simone Tripodi a écrit :
> >
> >>  - @deprecated in the javadoc is for human readability, @Deprecated is
> >> for the compiler;
> >
> > The compiler is fine with the javadoc tag, and the annotation doesn't
> > provide a useful comment to the user explaining why it's deprecated and
> what
> > to use instead. That's why I don't use this annotation.
>
> Depends on the compiler target. If you target 1.5 or later, then
> @Deprecated and @Override should be used.
>
> >
> >>  - @Override: I suggest you this reply on StackOverflow
> >> http://s.apache.org/q5s where justified the use of @Override
> >
> > The scenario described is not going to happen here. It's impossible to
> > change the signature of a method in a super class and forgetting to
> change
> > the subclasses without breaking a bunch of tests. In the end this
> annotation
> > just adds useless noise.
>
> Not useless - the intention is to prevent accidental override or
> failure to override.
>

+1

Gary

>
> >
> >>  - final: I would add also immutable fields
> >
> > Some fields might be immutable today but variable tomorrow. Why limiting
> the
> > options for the future now? There is no harm letting the fields as non
> final
> > and changing them later if necessary.
>
> That may break binary compatibility.
>
> It's better to start with minimum visibility and minimum mutability
> and relax as necessary, as that is generally binary compatible.
>
> Reducing visibility or mutability is generally not binary compat.
>
> Final fields are useful in helping to ensure thread-safety, but CLI is
> not the sort of library that really needs thread-safety, and making it
> thread-safe may require a total rew-write.
>
> Final fields also make debugging and testing easier, as there are
> fewer states to test.
>
> > On the other hand, you are going to
> > hesitate and ponder if the sky isn't going to fall if you have to remove
> a
> > final modifier later that was added without a very good reason.
>
> Removing a final modifier is less likely to cause binary compat. issues.
>
> > Emmanuel Bourg
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message