Craig Raw wrote:
> Hi,
>
> In order to add functionality to a class generated by JAXB, one has two
> options: inheritance or delegation. Inheritance is dodgy because of
> brittleness, the equals() contract, and appropriateness of this
> mechanism. As was pointed out in an earlier post, is XMLCustomer really
> a valid new type of Customer?
>
> Delegation, then, involves creating a class with the binding object as a
> member variable. Take BarDelegator with a member variable of Bar. It
> needs to implement the Bar interface as well, and delegates all Bar
> methods to the member variable. Additional methods with extra
> functionality can be added normally. Well and good.
>
> However, BarDelegator, in order to participate in the JAXB marshalling
> process, needs to do more. If you have interface Foo containing method
> 'getBar();' and 'setBar( Bar bar );', you will run into trouble
> marshalling a Foo which has had 'foo.setBar( barDelegator );' called on
> it. BarDelegator needs to implement 3 extra interfaces from jaxb-ri.jar,
> namely:
>
> com.sun.xml.bind.unmarshaller.UnmarshallableObject
> com.sun.xml.bind.serializer.XMLSerializable
> com.sun.xml.bind.validator.ValidatableObject
>
> If the methods these create in BarDelegator all delegate to the Bar
> member variable as before, all is well.
>
> No doubt this is old hat to experienced JAXB developers, but my question
> is: Is this a valid use of public API? The use of Suns interfaces seems
> to suggest not. If not, how 'published' are Suns interfaces? Are there
> any other ways to extend functionality of a jaxb class?
From the JAXB specification point of view, referring to the
com.sun.xml.bind interfaces is non-portable. Other JAXB implementations
will not implement these interfaces nor should they. The only
interfaces/classes that a portable JAXB application can use are
the schema-derived interfaces/classes and the classes reachable
from the packages javax.xml.bind.* and javax.xml.namespace.*.
Additionally, there are no guarantees against the JAXB RI internal mechanism
evolving in the future. Thus, dependence on the internals could
result in issues/problems in a release that follows v1.0.
Backwards compatibility is a goal of what is specified in the
specification, not on the internals of the reference implementation.
We hope to address this functional shortcoming of integrating the
schema derived classes with application behavior in the specification in a
future release.
Thanks for your feedback.
-Joe Fialli, Sun Microsystems
>
> TIA,
> Craig
>
> -
--