On 30 April 2013 22:15, Thomas Neidhart <[email protected]> wrote:
> On 04/30/2013 11:09 PM, sebb wrote: > > On 30 April 2013 21:54, Thomas Neidhart <[email protected]> > 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: [email protected] > For additional commands, e-mail: [email protected] > >
