My take on the current spec is that the mapping might actually restrict the field to only one type (or hierarchy), and throw ClassCastException or something similar for other types.
As Craig says, this is a mapping issue -- it's possible that my object model is defined to take Object, but my data model had as hard foreign key constraint that the field actually has to be an Employee. In this scenario I think the current spec is good. There are plenty of legitimate reasons (even disregarding Java5 generics) you might have a field of type Object but know as a programmer or deployer that it will only actually store an Employee reference.
Now, if we had a way to delineate exactly what types are defined as mappable for a field, it might be reasonable for the ORM part of the TCK to exercise these types (or one of them). Beyond that I don't think this should be part of the TCK.
Wes
Patrick Linskey wrote:
I do not think that the JDO spec should require that non-PC, non-primitive Object fields be Serializable. I am fine with the TCK not testing non-PC, non-primitive, non-Serializable Object fields, but this limitation should certainly not be put into the spec.
I'm ok with the spec requiring that non-PC, non-primivite, Serializable fields must be storable by an impl, but not with the converse.
