Joda - Next Generation Beans

Project
   Home
   SourceForge
   News
   FAQs
   Licence

Joda Time
   Time home

Joda Primitives
   Primitives home

Joda Beans
   Beans home
   Problem statement
   Design overview
   Getting started
   Swing binding
   XML input/output
   XPath access
   API Javadoc

Download
   Source
   CVS

Contributing
   Feedback
   Volunteer
   Contributors

 

 

 

 

 

 

 

 

Problem statement

The problem

The dominant object model in the world of Java is JavaBeans. This is not surprising as the interface to a simple bean is very simple - getSurname() gets a surname, setSurname() sets it. However, generic framework providers, such as XML bindings, GUI bindings, Servlet frameworks, have all had to rely on reflection and naming conventions. The result of this has been duplication of effort in each open-source/Sun project to access the JavaBean data, often with subtle differences between each implementation.

Over the last few years a second kind of object model has come to prominence - XML DOM. The DOM model treats all data as hierarchical, and introduces a whole set of terminology and restrictions for application programmers. To work around the weaknesses in the raw DOM API, other projects, such as JDOM, and DOM4J, have sought to provide a more Java friendly way to access the same kind of model. They have succeeded in that goal, but the interface is still unfriendly to those coming from a JavaBean background.

The result has been attempts by Sun and others to create JavaBeans which wrap the XML. Sun's proposal is called JAXB and seems to have had many false starts. These systems work by taking an XML document and code generating classes which represent the XML data. This approach has various flaws, including a reliance on static code generation and the creation of a model which looks like a bean but still has many of the design restrictions of XML.

Other models have also been created for particular purposes, notably the Swing GUI and JBDC record set models. The developer of a complex enterprise system often ends up spending their time converting data from one model to another.

To summarise:

  • Applications programmers like the ease of use of the JavaBean interface
  • Generic framework providers face difficulties extracting data from JavaBeans
  • Applications programmers, particularly from a JavaBean background, dislike the DOM style APIs
  • Generic framework providers can easily access and manipulate data from XML
  • Swing and SQL both have their own object models which do not work conveniently with each XML or JavaBeans

Solution >>