I think the fundamental issue regarding whether a TreeModel should be included in JAXB is not performance, but what JAXB is really designed for. Conceptually, adding a tree like interface to JAXB is the same as exposing the DOM interface to your application, and that is the first thing JAXB was intended to eliminate.
ND
On Tue, 28 Jan 2003 06:00:22 +0000, Les Hazlewood <les_at_hazlewood.com> wrote:
>Joe Fialli writes:
>
>> To enable the most generic implementation and to allow for future support
>> of
>> binding JAXB to existing Java classes, great lengths were taken to not
>> impose
>> any superclass on all schema derived interfaces.
>>
>> Requiring the TreeModel interface would have benefitted those who wish to
>> generically traverse JAXB data structures as a tree; however, there
>> would be a runtime performance overhead and usability issue for those who
>> did not wish that a TreeModel exists.
>
>The TreeModel and supporting classes (TreeNode, etc.) are merely interfaces,
>not implementations. Although adding TreeModel interfaces (even better yet,
>TreeModel interfaces specific to XML without Swing specifics) would slightly
>increase memory requirements for processing and instantiation, I feel the
>added functionality would far outweigh the added overhead.
>
>JAXB and well-formed XML, at their very conceptual core, are TreeModels of a
>data structure. To include "superset" functionality could only further
>empower the programmer and enhance acceptance and adoption of the Sun JAXB
>implementation.
>
>After all, the programmer already familiar with JAXB implementations would
>never even have to know about the added functionality. They could
>essentially ignore functionality (i.e. method calls) they don't require.
>
>Again, these are my opinions. I will wait and see what the next release
>holds.
>
>Thanks very much for your answers and explainations, I sincerely appreciate
>your time.
>
>Les Hazlewood