cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: @SuppressWarnings("unchecked")
Date Tue, 11 Dec 2007 15:32:01 GMT


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.   


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
P: 781-902-8727    C: 508-380-7194

View raw message