commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [collections] generics issues
Date Tue, 30 Apr 2013 23:12:19 GMT
On 30 April 2013 22:15, Thomas Neidhart <thomas.neidhart@gmail.com> wrote:

> On 04/30/2013 11:09 PM, sebb wrote:
> > On 30 April 2013 21:54, Thomas Neidhart <thomas.neidhart@gmail.com>
> wrote:
> >
> >> On 04/30/2013 10:49 PM, sebb wrote:
> >>> I've just been looking at fixing generics warnings in the test code.
> >>>
> >>> There are no current warnings in the main code.
> >>>
> >>> However, I've just discovered that this is because the warnings have
> been
> >>> suppressed, regardless of whether that is justified or not.
> >>>
> >>> I think this needs to be fixed before a release; it's quite likely that
> >>> some API changes will be needed. In turn these may change the test
> code.
> >>>
> >>
> >> Well, we have to look at them case by case
> >
> >
> > Yes.
> >
> >
> >> I did not add a single
> >> SuppressWarning so far myself).
> >
> >
> > Me neither.
> >
> >
> >> Most of them are needed because of casts
> >> from Object to the actual generic type, e.g. when doing a clone.
> >>
> >> Perhaps, but I must admit I don't understand some of them.
> >
> > For example in FunctorUtils:
> >
> >     static <T> Closure<T> coerce(final Closure<? super T> closure){
> >         return (Closure<T>) closure;
> >     }
> >
> > If the closure parameter is not of type T, surely the cast is bound to
> fail?
> > So why use <? super T> ?
>
> I think this is correct, and sometimes needed to overcome the wildcard
> madness


In other words: don't know for sure.

If we are sure that the warning is misleading - and cannot be avoided -
then we should use @SuppressWarnings with a comment to say why it's OK to
ignore the warning. Otherwise the warning should stand until it can be
fixed or safely ignored.


> (and it is in the package private FunctorUtils).
>
>
Does not matter; it's main code and can still cause unexpected crashes if
the assumptions are wrong.


> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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