Featured White Papers

• Java Web Hosting | DailyRazor.com - Over 10yrs Of Java Web Hosting Exp!

Sponsored Links

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Problems with Swing's new XMLOutputStream class

Find out what's wrong, from the perspective of object-oriented design, with the XMLOutputStream class that's part of the newest version of Swing

By Allen Holub, JavaWorld.com, 08/01/99

XML serialization

At the recent JUG meeting, Sun Swing team member Philip Milne discussed a new persistence mechanism that's going to be added to Swing for the specific purpose of supporting file-based storage of JavaBeans. The long and the short of it is that an XMLOutputStream class, which works much like the classic ObjectOutputStream class (which flushes a binary version of an object to an arbitrary OutputStream), will be introduced into Swing. Objects sent to an XMLOutputStream are written out in a human-readable, XML-based syntax. This mechanism only works with JavaBeans, though; unlike ObjectOutputStream, you can't use it to store generic objects.

Personally, I'm not much of a fan of XML. I really like the idea of representing arbitrary data using a well-defined ASCII syntax, but XML itself is not a particularly good syntax for this purpose. Why not? Well, for one thing, it's just not compact enough. I much prefer something TeX-like, as in {b boldface} -- which is not only compact, but also enforces nesting in an intuitive way -- to XML's (<b>boldface</b>). Moreover, the whole notion of a DTD, a significant part of XML, is obscenely complicated for what it does. (For an introduction to XML, see Mark Johnson's JavaWorld article, "XML for the absolute beginner.") Why not just use a standard BNF grammar?

Regardless of my (or your) feelings about XML, one good thing about it is that it allows us to store the state of a JavaBean to a file in a well-defined, human-readable way. My problems with the new system have to do with the implementation presented by the Sun Swing team, not with the fact that it's using XML. Since the focus of the designers of this subsystem was on beans, the implementors correctly concluded that there was no point in storing the state of the entire object, since you can do this with standard serialization if you need to; rather, only the properties of the bean are stored to disk, and the list of property values is used to recreate the bean when it's reloaded. To reduce the size of the file, the persistence system creates a default instance of the bean (using the default constructor) and only stores those properties that do not have default values.

Unfortunately, the mechanism that's used to determine what properties need to be stored is at odds with both the JavaBeans specification and the principles of good object-oriented design. JavaBeans has always supported two ways of telling a BeanBox tool about properties. (A BeanBox is a drag-and-drop UI layout tool that's JavaBean-aware. The term was originally used to describe Sun's JavaBean Test container. See Mark Johnson's "The BeanBox: Sun's JavaBeans test container.") The simplest way to specify a JavaBean is to use getter and setter methods (more properly called accessors). Get/set functions are fundamentally incorrect in an object-oriented system, as I discussed last month. Exposing these compile-time properties to the runtime system by means of get/set methods is just unacceptable to a good object-oriented designer.