On Tue, Sep 1, 2009 at 10:55 AM, ljnelson<ljnelson_at_gmail.com> wrote:
...
> And I have in mind that somehow {handwave, handwave} the returned XML would
> as magically as possible be correct (suppose T evaluates to Foobar):
>
> <foobars>
> <foobar>First result item</foobar>
> <foobar>Second result item</foobar>
> </foobars>
>
> Now, as it happens, I have to subclass the DAO anyway for each type of
> object. This is in part so that the EJB interface it's called through
> correctly reflects the right type. That is, I would have to create a class:
>
> public class FoobarDAO extends AbstractDAO<Foobar, FoobarPrimaryKeyClass> {
> /* ... */ }
Yes, and this would add necessary type information for full type resolution.
> Is it possible that if THIS class were invoked I would get back the proper
> XML from its findBySomeCriteria method?
As far as I understand this: yes, if and only if you do provide
concrete typed sub-class. Otherwise type erasure will, well, erase
runtime(-accessible) type information.
Type information is needed for proper binding, and the only place
where runtime-accessible type information is stored is within Class
objects (including Field and Method objects). If there is no concrete
sub-class, there is no accessible type information. Specifically, any
type decoration within casts (or implicit coercion by compiler) only
affects bytecode produced, and can't be used by runtime.
So, it's probably best not to fight against sub-classing: it's
necessary if ugly thing. :)
For what it's worth, there is one alternative way to address this
problem from framework perspective: by using Annotations for typing.
But annotations do not help with more dynamic cases, which seems to be
what you had in mind (i.e. trying to have just one method overall, not
one per type).
-+ Tatu +-