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