I have stopped using JAXB because of the points mentioned. After evaluating JAXB, Castor, and several others, Digester from Jakarta/Apache offers exactly the model I need and integrated with a huge code base developed over a period of two years in less than a day. It does not offer the validation or marshalling capabilities of JAXB and these are of course critical, so now I am looking into Betwixt which uses Digester for those.
With all due respect, a spec that does not address the case of existing classes and specifies an entire object hierarchy based on a single schema appears more academic than useful.
Leon
*********** REPLY SEPARATOR ***********
On 01/25/2003 at 8:10 AM Andrew Wellman wrote:
>All,
>I agree with many points in this email. I am using a lot of JAXB in my
>applications. Mostly I use it to load in properties files, like files
>with queries and validation fields, etc... Since these files are loaded
>in at the time of app server start up, performance is not a major factor
>for me either. I am not saying its poor, I just didn't really have to
>consider it. Once the server is up, I am just talking w/ domain
>objects.
>
>In one instance I am storing a stateful application as XML. Users can
>fill out the application in stages and in many different sessions, thus
>I have to be able to easily jump into the middle of my XML file. The
>end goal is that the XML is converted in MISMO standards using XSL and
>going to be sent over the wire as a web service for underwriting, credit
>reports, etc... Its a lot easier to call setBorrower() and pass a
>domain object instead of traversing DOM and placing it in the right
>area. Validating my own DOM code would be 10X tougher.
>
>other points in-line.
>
>Regards,
>Andrew Wellman
>
>>
>> When you read an xml document in java you take the data that you find,
>> and either create objects with it, or pass it to objects; in either
>> case you're giving it to objects that will internalise and encapsulate
>> it.
>
>Yes, Yes, Yes. Who wants to write DOM/SAX code? It is very ugly and
>not
>maintenance friendly code.
>
>>
>> If you just use the data directly then you're not developing in the OO
>> paradigm, and perhaps shouldn't be using java. If you're just taking
>> the data, and creating new xml documents out of it, then you should be
>> using xsl. But, if you are writing an OO system, then you'll want to
>> put the data into domain objects - objects that model the solution
>> domain of you system(classes like Customer, Address, etc).
>
>I also agree with this. Its nice to have an object that I understand as
>the end product, as opposed to having to look at schemas or DTDs all day
>to understand my data.
>
>>
>> Right now you're writing DOM or SAX code to read the xml document, and
>> writing code that takes the resulting data and puts it into the domain
>> classes. This is what JAXB does for you. It creates entity classes
>> that you can use from your domain classes.
>
>You would hope that the code ends up in Domain classes. If not its even
>more poor than just SAX/DOM.
>
>>
>> Your schema may change, but your domain model will probably remain
>> fairly static. In this scenario, when the schema changes you'll
>> generate a new entity model and make the relevant changes in your
>> domain model to access it. This could be as simple as changing a
>> single attribute name. If you were using DOM or SAX then you'd have to
>> change a lot more, write tests for it, run the tests, fix the
>> implementation, run the tests again, refactor, etc.
>>
>> There are other benefits too. If you *can* assume that the JAXB
>> implementation you're using generates defect free code, then you don't
>> have to spend time testing that code, and you don't have to look there
>> for defects when they arise in your system. Everything you write by
>> hand you have to distrust, test, and continually confirm.
>
>Exactly! Its almost like having your own pre-defined component. Since
>there
>are several vendors doing JAXB you have a choice of who ever puts out
>the
>best product. This will especially true as it becomes standardized.
>
>>
>> The arguments for using JAXB over DOM or SAX where a schema is
>> available are persuasive. I can find no good reason to directly use
>> DOM or SAX again.
>
>I have some legacy SAX that I am too lazy to migrate, but that's it.
>Otherwise,
>I use JAXB and XSL as frequently as possible.
Leon Smith
California Software Studio
Phone: 530.877.1787
www.CaliforniaSoftwareStudio.com