Clean code

Most data binding frameworks are XML-centric. You start with a grammar for your XML documents (usually in the form of a W3C XML Schema) and use that to generate a set of classes that match the XML structure. With some frameworks you can subclass the generated classes, in others you may be able to implement generated interfaces in your own classes and use these classes in place of the generated ones. Either way, you still need to match the class structure expected by the binding framework.

JiBX is deliberately Java-centric. It does not force a structure on your Java classes, other than that there be some reasonable way of linking particular properties of class instances to components of the XML document. This lets you define classes that match your needs, not just the (often arbitrary) structure of the XML. It also lets you refactor your code over time without needing to change the XML structure each time to match.

This is an especially important feature because it allows you to use true object-oriented structuring of your code. The frameworks that force you to work with a generated set of classes generally limit you to using JavaBean-like objects - basically just collections of fields with get and set methods added, only cosmetically different from a C-language "struct". True object-oriented programming requires combining behavior with state (data), and hiding as much of the internal state as possible from clients of an object. JiBX is designed to encourage this style of development.

JiBX also avoids cluttering your Java source files with generated code. Because it uses class file enhancement rather than source code generation, it can stay out of your way - you normally won't even see the JiBX code at all unless you use reflection on the enhanced classes (though it's possible to decompile the enhanced classes to get source, if that's what you really want).

This doesn't mean that JiBX is ideal for all applications. Code generation from a schema instance is a great way to get started quickly on working with a particular type of XML document. Code generation also helps assure that your code always matches the XML document structure, and many of the code generation approaches allow for full validation against the document grammar.

In the future it'd be great to add support for code (and binding definition) generation to JiBX, and nothing in the design in any way prevents this from being done (in fact, see the Xsd2Jibx and Generator Tools subprojects for the current work in these areas). We're also planning to support J2SE 5.0 annotations for embedding simple binding definitions directly in the source code. An annotation-based approach will not allow the same level of flexibility as provided by a binding definition file, but will be convenient for users who want to keep a close correspondence between their Java class structure and the XML representation.