Kohsuke Kawaguchi wrote:
>Les Hazlewood <les_at_hazlewood.com> wrote:
>
>
>>In JAXB beta, I could do:
>>Car car = garage.getCar();
>>
>>Now, I can't do that....
>>
>>Instead, with JAXB 1.0 in the JWSDP, I have to do:
>>
>>CarType car = garage.getCar();
>>
>>I HATE this. Its incredibly unintuitive. Conceptually, I want to operate
>>on a CAR, not on a CarType.
>>
To support type substitution in the future and element substitution in
JAXB standard implementation 1.0.1
extension mode, it is mandatory that all getter signatures be specifed
as their Java representation for
the element's type definition, not the element's interface.
Type substitution mandates that JAXB java representations work with the
types of the elements,
not the actual element interfaces.
Given following XSD constraints:
Type Definition Hierarchy
Element
CarType
<xsd:element name="Car" type="CarType"/>
^
/ \ derivation by extension
/ \
DomesticCarType ForeignCarType
And the following valid XML document instances for these constraints:
<car> .....</car>
<car xsi:type="DomesticCarType"> ..domesticcartype content ... </car>
<car xsi:type="ForeignCarType"> ..foreigncartype content ... </car>
The method getCar() has to be able to return instances of ForeignCarType
and DomesticCarType, if complex type def CarType allows for type
substitution, which is the
default behavior in XSD. If getCar() returned a Car element, JAXB would
not be able to
easily support type suntitution in a future release.
For element substitution, consider the case of elements Car,
ForeignCar, and DomesticCar all belonging to the
same substitution group with Car being the head element. The method
setCar(CarType) works and accepts instances
of all elements in the substitution group since all elements are of
types that derive from CarType. This would not
work if setCar(Car value). Only the element instance Car could be passed
for this case. Other scenarios exist
in XSD where the "element" may not exist at all in the schema but the
xsi:type does and that is all that is necessary,
for example wildcard context processContents="lax".
By the way, the JAXB v1.0 specification does not mandate that the getter
return an instance of CarType or
one of the element instances of Car, ForeignCar and DomesticCar.
All the specification requires is that the returned instance implement
the interface for CarType.
If an element interface is generated for element Car, a JAXB
implementation could return an instance of Car element interface for the
above case.
As an optimization, JAXB tries to avoid generating Element interface
when they are not necessary, this
cuts down on the number of generated classes, especially when there is
one to many relationships between
a complex type definition and element declarations(with some being local
element declarations).
Thanks for your feedback.
-Joe Fialli, Sun Microsystems
>>
>>
>
>Well, I felt in the same way before. But the spec is clear on this, and
>therefore as an implementor I have no choice but to follow the spec.
>
>I think the rationale is that making it a CarType allows you to cut &
>paste that object into other places where a CarType is expected.
>
>And since Car is just extending a CarType without adding any significant
>method, I'm not so sure if it causes real pain in reality.
>
>But your input is very welcome. There might be even somethng we can do.
>
>
>regards,
>--
>Kohsuke KAWAGUCHI 408-276-7063 (x17063)
>Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
>