The State of JAXB: Availability, Suitability, Analysis, and Architecture
Subject:   java.beans.XMLEncoder/Decoder
Date:   2004-05-06 21:29:52
From:   jxtaboy
If you need an simple code-centric way to marshal and unmarshal Java objects to XML, you can use java.beans.XMLEncoder & XMLDecoder. These classes are meant to replace ObjectInputStream/ObjectOutputStream and they work virtually identically, in that they are able to encode/decode any JavaBean-compatible type. The downsides to this approach are that the XML is more bloated than it needs be, and interoperability is tougher due to the fact that no specific schema is generated for the bean. However, the DTD used by XMLEncoder can be found at
Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • java.beans.XMLEncoder/Decoder
    2004-05-10 12:39:50  satyak [View]

    Thanks for the input. I haven't looked into XMLEncoder and Decoder. Perhaps as you have suggested they could be use for light weight uses which in my mind are quite a few. Again thanks for the pointers. Nevertheless it is interesting that we separate these XML data binding needs as serialization needs and data exchange needs although what is produced is XML in both cases. I think XML serialization is much more loose and lossy and problem domain specific and can cover more than object persistence. I don't think lumping this kind of serialization for XML generation doesn't suit the problem space either. We need a ground between this and JAXB. It would have been nice to see such a facility as part of JAXB. In fact there are suggestions in the JAXB architecture that perhaps it is possible to provide JAXB implementations without requiring an XSD or an alternative schema.