Apologies if this proves less that coherent. As it was first built, Aegis centered around a map that connected Java types (specified as Class objects) and Aegis 'Type' objects. A type object does reading and writing.
Obviously, such a system will treat all List<x> objects as the same thing. Pre-Java-5, Aegis supported List and Map via XML specs that stated, for a particular method parameter or bean property, what to use as the list component or map key and value. In this situation, instead of using a generic Aegis Type object, a new one gets instantiated and hung onto by either the service model (for a parameter) or the 'BeanType' object. For Java5, this was enhanced with code that would look at the java.lang.reflect.Type information to obtain the same information. The type mapping is also used to get from xsi:type attributes to types. In the generic case, this leads to a somewhat incoherent situation. The type mapping is bidirectional: it can map a type QName to an Aegis type, or a Class to an Aegis type. For these filled-in generics, they fight with each other in the type mapping to map the Class, but they they can be unique in the QName direction. This more or less works, since the xsi type reading case only looks up by qname, and, when writing, the specific Aegis Type is available and need not be obtained from the map. Due to the duel over the Class slot in the map, there has been internal disagreement in the code over whether these specific types get registered or not. My nose has been rubbed in all of this by the JAX-RS situation. JAX-RS wants to be able to read a message, specifying what to read via both a Class and a full java.lang.reflect.Type -- in other words, a full generic. Now, if the map mapped 'Type' instead of 'Class', it would seem possible to make all this cohere. List<a>, List<b>, and List<c> could all be distinctly mapped. However, working with java.lang.reflect.Type and it's subclasses is not so easy. The API has some gaps. In particular, I see no way to get from "java.util.List' and "java.lang.Integer" to a ParmeterizedType object for List<Integer>. I feel as if I must be missing something, since javac must do something like this somehow. So, say that I wanted to move Aegis to book-keeping in Type. There are plenty of things that happen that require Class. Things get newInstanced, for example. So in some places it would be critical to have both a Type and a Class, or at least to have a very convenient utility for the rigamarole to get from one to the other. If I can't manufacture a ParameterizedType on demand, I have to either get rid of the old Java 1.4 support for properties of naked collection types with XML to fill in, or I need some object that is the 'union' of a Type and a manual description to use in mapping. Before I do either of this things, I thought I'd see if anyone else knows a better way.
