Possible advantages of X2J - Primary Keys

I've been thinking a lot about where the X2J framework I'm toying with. I've thought of several problems with XML binding, and several nice solutions. I will give examples of the problems using JAXB, as I know it better than the other frameworks for binding and serialization. I will discuss one problem now, but you are welcome to read all the coming additions to X2J, as shown in the feature requests I've set for myself on the SourceForge page.

Repeating objects

When in JAXB you have a couple references to the same instance. As an example, think of a Schedule instance referencing the same Lecture instance at different time slots (represented by some array contained inside the Schedule instance). When it will be serialized by JAXB, each Lecture item will be serialized separately, as it should be; However, when deserialized, multiple Lecture instances containing the same data will be created. This is, most of the times, unexpected at first use of JAXB for serialization. Luckily, frameworks like XStream do a better job - But they change the way you'd expect to see an XML generated from the serialized class, so that most of the times using XStream for serialization means you have to use it for deserialization as well (Which isn't that bad!)

My suggested solution is reflected in feature request 1380327:

Add a @PrimaryKey annotation, or a value inside the @Attribute
annotation. This will tell the framework to map this object by a
certain primary key, and whenever there is another object with the same
primary key it will be taken from the cache and placed instead of being
parsed.

So that while parsing the data, objects with a set primary key would be cached according to their primary key, and when the same primary key is encountered, the cached item will be set to the referencing object. This way, the generated object tree is created as expected.

Related Posts
X2J on the firing line
XML to POJOs project is in the air