My proposal is to make the reader and writer non-generic. That why I
think you'll hate me.
Let's see if Dain proves me stupid.
On Tue, 2007-12-11 at 14:10 -0500, Daniel Kulp wrote:
>
> On Tuesday 11 December 2007, Benson Margulies wrote:
> > So, if I did something slight violent to the DataBinding / DataReader
> > model to allow elimination of the warnings, we'll still be friends?
>
> If you can figure out how to get the Reader/Writers to work without it,
> I'm definitely open to the changes. I tried a long time ago to
> eliminate them, but couldn't figure out a solution.
>
> Dan
>
>
> >
> > 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?
>
>
>
