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:26:41 GMT


On Tuesday 11 December 2007, Benson Margulies wrote:
> My proposal is to make the reader and writer non-generic. That why I
> think you'll hate me.

Well, then we'll need to add casts in other areas of the code.  (Which 
may be OK).  The "read(T input)" methods would need to make "input" just 
an Object and the cast it to the appropriate type in their code.  

That said, the other reason to not do this is that it would break any out 
of tree data bindings and probably bindings as well.   Example: I'm 
pretty sure it will break the Yoko stuff (although that can easily be 
fixed while merging it into CXF).  

Dan



>
> 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?



-- 
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