Next step in the Aegis Modularity process

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

I created a 'CXF-independent' data reader. Obviously, it will need a
matching writer.

I used this opportunity to see how to avoid
@SuppressWarnings("unchecked").

Here's what I came up with. Note, I did NOT change the core CXF API for
databinding. This Aegis-specific API might be contemplated as a model
for a warning-free CXF alternative.

Here's the function of the evening. Note that this is Generic-ed over
two types. The type of the reader object (which is returned) and the
type of the source. As always with Generics, the caller has to pass in a
class reference to the type that comes out. Since there is no such thing
as a class reference to a specific instance of a generic class (see
'type erasure', the type has to be a class, not an instantiated
interface.

AbstractAegisDataReaderImpl defines no read API. Since the read API
takes an object of the input type, the caller has to know what it is.
That class defines the non-source-sensitive part of the protocol.

Thus, to acquire a reader, the code would call,

createReader(AegisXMLStreamDataReader.class, Element.class) (for
example).

The two parameters might be judged clumsy, but consider a call to

createReader(AbstractAegisDataReaderImpl.class, Element.class)

The resulting item could be later downcast to a specific reader,
allowing there to be a 'generic' function responsible for returning the
reader object.

Anyway, I'm open to editorial commentary here.




    public <Reader extends AbstractAegisDataReaderImpl, Source> 
    Reader createReader(Class<Reader> readerClass, Class<Source>
sourceClass) {
        if (sourceClass == org.w3c.dom.Element.class) {
            return readerClass.cast(new AegisElementDataReader(this));
        } ...
        return null; // throw?
    }