users@jaxb.java.net

JAXB - the return of procedural programming?

From: Clay <jaxb_list_at_CLAYMCCOY.COM>
Date: Fri, 21 Feb 2003 10:37:40 -0700

This message was originally submitted by jaxb_list_at_CLAYMCCOY.COM to the
JAXB-INTEREST list at JAVA.SUN.COM. If you simply forward it back to the list,
using a mail command that generates "Resent-" fields (ask your local user
support or consult the documentation of your mail program if in doubt), it will
be distributed and the explanations you are now reading will be removed
automatically. If on the other hand you edit the contributions you receive into
a digest, you will have to remove this paragraph manually. Finally, you should
be able to contact the author of this message by using the normal "reply"
function of your mail program.

----------------- Message requiring your approval (17 lines) ------------------
I'm new to JAXB. So go easy on me please. I am have a problem with unneccessary limitations that I see in JAXB, and how this results in a nonobject oriented programming style.

I am working on an application that gets data from a database, organizes it in memory, and writes it out to XML. I have already developed a similar framwork that parses a dtd and using that information it can deal with XML in a hierarchy of very generic container classes. These container classes are smart enough to do a few common taskes like write themselves out as xml, and load data into themselves. This works great, and where something specific is needed I can subclass one of the generic container classes and add some specific behavior like a particular sorting, calculation, loading of data, or manipulation of containers below it in teh tree.

Now JAXB comes along and I am suppose to incorporate it into my program. Well, at first glance it doesn't seem to be the total solution to my problem, and I don't really need it. I have two main problems with JAXB that I am hopeing that someone can help me address.

First is that I do not want to deal with the tedious process of calling each getter and setter. It also seems bad that you should have to change the code that operates on your JAXB generated classes every time your schema changes. In my xml framework that I describe above, all the data is stored in a hierarchy of glorified maps with the xml tag name as the key. Data can be get and set by the names that the program already knows from readign in the dtd. It is all generic and dynamic so there is no need in writing long procedural classes full of getting and settign specific data that has to change every tiem the schema does. But there doesn't seem to be an easy way to do this in JAXB. It seems that you have to implement your own middleware that uses reflection.

Second, is that my generated container classes are dumb and I have no control over that. The logic that I want the objects to have can not be in these objects. And I can't easily subclass a JAXB generated class and add behavior to it. So where do I put behavior that I want to go along with these objects?

The combination of these two issues make it seem that the quick answer anyway, is to have a big procedural program that contains all the logic for the generated container classes and data operations. Not only that, but this hardcoded specific procedural program will have to change for any little change that is made to the schema. That's just lame. Somebody please show me an elegant way of dealing with this.

Thanks,
Clay


PS. After the tedious process of logging into this e-mail list I still can't seem to view the archive, yet I can post.