Skip to main content

Why not JAXB for markup marshaling?

2 replies [Last post]
Anonymous

One design question, why did the JDNC team decide to go with their own
XML to POJO project (OpenMarkup) rather than using JAXB?

I feel that one of the big advantages would be a more common API that is
used commonly (JAXB2.0 is supposed to be used by JAX-RPC 2.0 IIRC)
rather than yet another home-grown api. This would be especially useful
when attempting to add extensions to JDNC markup that may not be meant
for use inside of the core JDNC (like say custom components that one
would want some configurability with).

--Danno

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> Why did the JDNC team decide to
> go with their own XML to POJO project (OpenMarkup)
> rather than using JAXB?
>
The JDNC team did start with its own XML to POJO (Plain-old Java objects) code when the project was initially launched, but a little more than a year ago, decided to scrap that, because the resulting objects were anything but POJO :-) They had all kinds of XML-specific code intermingled with component-specific code. What we really wanted was a clear separation between the two, in order to keep the code maintainable and to ensure that developers who don't use XML don't have to pay the price for it.

At the time, we took a fresh look at JAXB, and concluded that it wasn’t going to work for us (more on this below). So, the alternatives were to build yet another home-grown solution, or to look elsewhere. This is where OpenMarkup comes in. OpenMarkup is not a Sun project, but an open source object realization api from eNode (http://www.enode.com) that predates the JDNC project. The OpenMarkup api has certain qualities that make it especially attractive for the JDNC vision (more on this below).

> I feel that one of the big advantages would be a more
> common API that is used commonly ...
> rather than yet another home-grown api. This would
> be especially useful when attempting to add extensions
> to JDNC markup that may not be meant for use inside of
> the core JDNC (like say custom components that one
> would want some configurability with).
>
> --Danno

First of all, JAXB is about translating an XML document into a schema-specific content *tree* (like DOM). In contrast, the OpenMarkup api is about realizing finished object *graphs* from XML documents.

A simple example should illustrate the point: Let's say, a schema defines two element types "splitPane" and "table", where

might appear under . What JAXB will do is compile the schema into a set of element implementation classes, like SplitPaneImpl and TableImpl, whose instances are returned by factory methods createSplitPane() and createTable().

JDNC, on the other hand, wants to realize an instance of javax.swing.JSplitPane for , and org.jdesktop.jdnc.JNTable for

. Obviously, both JSplitPane and JNTable must necessarily be defined outside of JAXB. Also, many of the attributes on these elements are more than simple properties on the corresponding objects, which attribute appliers in the OpenMarkup api handle with ease, but JAXB can't.

Moreover, a faithful realization of the element in this example requires that the

element be assimilated into the element by calling api that is specific to the realized object (JSplitPane.setLeftComponent, or equivalent, in this case) -- something that is not possible with JAXB-generated code.

When a document containing these elements is presented to JAXB-generated classes, the developer gets a content tree that he/she must explicitly manipulate or post-process in application-specific ways to realize any object graph. In contrast, users of OpenMarkup simply ask for realized object graphs from an object realizer. An object realizer picks up where the parser and document builder leave off. The object realization framework and tag libraries are never considered part of the application.

This is what convinced us that JAXB was not the right technology for object realization, and that OpenMarkup was a better fit for what JDNC needed.

To address your concerns, the OpenMarkup vision calls for extensibility and configurability at all levels (language definition, object realization framework, and tag libraries).

OpenMarkup api recognizes that even well-defined languages might need to be extended, perhaps by adding new attribute(s) or element type(s) from the same or different namespace, with or without access to a machine-readable schema. Requirements to support custom components might also vary. For example, some might want to use a more configurable custom component for a predefined element type, while others might want to define a brand new element type for a user-defined component. And all of this would have to be easily implementable (in a variety of ways) using standards (like JAXP and W3C DOM apis), wherever possible.

The OpenMarkup api supports all of these, and embraces standards wherever possible.

It supports compound documents, with elements from multiple namespaces. Unlike JAXB, it does not require a machine-readable schema to be useful. It allows users to substitute custom components that are realized from predefined element types. It allows more sophisticated developers to define their own XML vocabulary, grammar, and tag libraries for their own custom components. Of course, users of OpenMarkup don't need to implement their own object realizer, but if there is ever a need, the OpenMarkup api can be easily implemented -- The Sun object realizer was implemented in just a few weeks.

The bottom line is that the object realization needs of JDNC are more complex than what JAXB unmarshalling provides today. The OpenMarkup api has proven effective for the JDNC markup language, as well as for other domain-specific languages.

wangzx
Offline
Joined: 2003-07-24
Points: 0

>
> At the time, we took a fresh look at JAXB, and
> concluded that it wasn’t going to work for us (more
> on this below). So, the alternatives were to build
> yet another home-grown solution, or to look
> elsewhere.
I think so, the JAXB 1.0 is suitable for map xml to java, but not map java to xml, so it is good at process xml, and provide a better way than DOM or SAX. but as a Java developer, we need to focus on java, including model with java, design with java, and coding with java. we need a Java(POJO)-XML mapping.

the current JAXB2 specification looks fix the gap, it now support using JSR175 annotation for POJO, and can provide a more nature way for mapping Java to XML, i feel that JAXB2 is more easy to using than OpenMarkup.

>
> > I feel that one of the big advantages would be a
> more
> > common API that is used commonly ...
> > rather than yet another home-grown api.
I hope that JDNC team would migrate to JAXB2 as soon as the JAXB2 is available. although OpenMarkup can provide the same function, but it is not as simplely as JAXB2, and not extensible as JAXB2, in JAXB2, any POJO can be marked without any code, so JDNC will be more extensible and more easy to extended. I dont like SWT not because it works bad, but it disintegrate the Java world, and provide a uncompatible API to the java world. So we require a unified POJO-XML mapping standard, i think JAXB2 is more than OpenMarkup.