@SuppressWarnings("unchecked")

[Benson Margulies <bi...@gmail.com>]

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?
 

Re: @SuppressWarnings("unchecked")

[Benson Margulies <bi...@gmail.com>]

Dain,

It is bad because I don't know how to make it work without warnings.

The prototypical function for this looks like:

public <T> DataReader<T> getReader(Class<T> clazz) {
}

If you can tell me how to code this so that it doesn't get a generic
safety warning, I'll happily apply it.

There is no really good reason for DataReader<T> as opposed to
DataReaderT, as far as I can see. 




On Tue, 2007-12-11 at 10:49 -0800, Dain Sundstrom wrote:
> +1 to eliminating all @SuppressWarnings("unchecked") annotations that  
> can be with CastUtil and good use of generics.
> 
> I don't really understand #3 below.  Can you explain why this form is  
> bad?
> 
> -dain
> 
> On Dec 11, 2007, at 5:11 AM, 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?
> >
> >
> 

Re: @SuppressWarnings("unchecked")

[Dain Sundstrom <da...@iq80.com>]

+1 to eliminating all @SuppressWarnings("unchecked") annotations that  
can be with CastUtil and good use of generics.

I don't really understand #3 below.  Can you explain why this form is  
bad?

-dain

On Dec 11, 2007, at 5:11 AM, 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?
>
>

Re: @SuppressWarnings("unchecked")

[Benson Margulies <bi...@gmail.com>]

Well, really, I was going to give each derived class an independent read
method (or write) that just takes the relevant type.

getReader(Class<T> t)

would return some subclass of DataReader (no <T>).

XmlStreamReaderDataReader would have a read(XmlStreamReader), etc.

By definition, there is no need for the read or write method to be
abstract. The callers of read and write know what type they are using.

As best as I have been able to internalize, this is what the Java gang
thinks they intend to support.




On Tue, 2007-12-11 at 14:26 -0500, Daniel Kulp wrote:
> 
> 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?
> 
> 
> 

Re: @SuppressWarnings("unchecked")

[Daniel Kulp <dk...@apache.org>]

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

Re: @SuppressWarnings("unchecked")

[Benson Margulies <bi...@gmail.com>]

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

Re: @SuppressWarnings("unchecked")

[Daniel Kulp <dk...@apache.org>]

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

Re: @SuppressWarnings("unchecked")

[Benson Margulies <bi...@gmail.com>]

So, if I did something slight violent to the DataBinding / DataReader
model to allow elimination of the warnings, we'll still be friends?

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

Re: @SuppressWarnings("unchecked")

[Daniel Kulp <dk...@apache.org>]

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