So, if I did something slight violent to the DataBinding / DataReader
model to allow elimination of the warnings, we'll still be friends?
What we need is a way to discourage the use the @ suppressor when there
isn't a really good (old collections) reason.
On Tue, 2007-12-11 at 10:32 -0500, Daniel Kulp wrote:
> Benson,
>
> I'm completely +1 to removing any of the @SuppressWarnings("unchecked")
> things that are in there if they can be eliminated. I used to
> periodically go through and grep for "unchecked" and fix them, but I've
> been too busy to do that for MANY months.
>
> The main issues is when using collections from Java 1.4 code. The big
> offender is WSDL4J. However, we did create the CastUtils class to
> provide casts for those situations.
>
> Dan
>
>
> On Tuesday 11 December 2007, Benson Margulies wrote:
> > In general, the CXF rules insist that we avoid Java constructs that
> > produce warnings. One significant exception to this is generics.
> >
> > CXF has a significant population of @SuppressWarnings("unchecked")
> >
> > I would like to open for discussion (and possible vote) a proposal to
> > clean them all up and then treat them as errors.
> >
> > In my perhaps unfair opinion, these cases often look like the standard
> > results of expecting Java generics to have the same flavor as C++
> > parameterized types. More specifically, I see three categories:
> >
> > 1) Simple failures to use the 'cast' method. These are cases where a
> > generic method has the right signature, but is using a () cast and
> > @SuppressWarnings("unchecked") instead of class.cast(value). When I
> > see these, I fix them.
> >
> > 2) Not enough Class<T> arguments to functions. The most common C++
> > crossover is to think that from public <T> T somefunction() you can
> > return a T without adding Class<T> to the arguments. When I've seen
> > these with a few spare minutes, I've fixed them as well.
> >
> > 3) The hard cases. The Databinding methods that are writer and reader
> > factories are the big examples here. The functions take Class<T> and
> > want to return SomeClass<T>. I have not yet figured out the
> > alternative here. Arguably, the whole idea of DataReader<T> as opposed
> > to XXXDataReader extends DataReader is an example of round C++
> > parameterized type thinking trying to be inserted into a square Java
> > generic hole. With all due respect to the author(s), I'd offer for
> > consideration refactoring this code to just extend a base class
> > instead of being a generic.
> >
> > Thoughts?
>
>
>
