Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of bimargulies@gmail.com
 designates 64.233.184.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding;
        b=QGf1z+DGZt+537aHBM5an0Fxhdtr1nlDIsfoDknC1BlXAoWMIlvpcBFN0hVOA7s8BynWe0ZqCuFfNclly1ykIXJexXUeAGJnsR7guXr1/xWGTmZMLMSLHIxOzs0K1KmZtowNt6kMoapILtkKZFjhTKPgKKmIMX/20+S1Wg3ibxQ=
Subject: @SuppressWarnings("unchecked")
From: Benson Margulies <bimargulies@gmail.com>
To: cxf-dev@incubator.apache.org
Content-Type: text/plain
Date: Tue, 11 Dec 2007 08:11:09 -0500
Message-Id: <1197378669.6915.8.camel@bim1330.basistech.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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?