cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: @SuppressWarnings("unchecked")
Date Tue, 11 Dec 2007 19:10:49 GMT


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?



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Mime
View raw message