Dain,
It is bad because I don't know how to make it work without warnings.
The prototypical function for this looks like:
public <T> DataReader<T> getReader(Class<T> clazz) {
}
If you can tell me how to code this so that it doesn't get a generic
safety warning, I'll happily apply it.
There is no really good reason for DataReader<T> as opposed to
DataReaderT, as far as I can see.
On Tue, 2007-12-11 at 10:49 -0800, Dain Sundstrom wrote:
> +1 to eliminating all @SuppressWarnings("unchecked") annotations that
> can be with CastUtil and good use of generics.
>
> I don't really understand #3 below. Can you explain why this form is
> bad?
>
> -dain
>
> On Dec 11, 2007, at 5:11 AM, 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?
> >
> >
>
