Blogger: Chris Haddad
Recent lively team debates have focused on J2EE merits and drawbacks. We are amazed by JavaLand’s suburban API sprawl and propose that there is a strong need for simplifying the J2EE platform stack before the platform collapses under its own weight, redundancy, and complexity.
For example, do we *really* need another data/resource access API? The JSR 225 team thinks so, and has proposed XQuery API for Java (XQJ), http://jcp.org/en/jsr/detail?id=225. We already have Java Data Objects (JSR 12, 243), JDBC (JSR 54, 221), Java Persistence (JSR 220, 317), Data Mining (JSR 73, 247), and JDBC Rowset Implementations (JSR 114).
After reviewing the 120+ page XQJ specification, I wonder why so much effort was spent creating an API that overlaps so heavily with other Java resource access APIs and is not layered on top of generic interfaces. Are specialized XQuery oriented Connection, DataSource, and ResultSet objects really required? Couldn’t we have re-used persistence objects already defined? If not, is this evidence that the original Java specifications should be reviewed from the ground up and heavily re-factored?
The XQJ specification does not exhibit architectural principles of composition and derivation. Some key nits:
- Why does the specification rename XML Schema type definitions as ‘new’ XQJ constants instead of referencing existing constants?
- Why does the specification present ‘Java to XML Schema type mappings’ instead of referencing JAXB specification definitions?
- Why are XQConnection, XQDataSource, XQDataFactory, and XQResultSequence not derived from non XQuery specific base classes or extending generic interfaces?
Other examples of suburban sprawl are evident in Java messaging, serialization, and XML manipulation. Java should not represent ‘tyranny of choice’. I am coming to the conclusion that the Java platform is going to collapse under it’s own weight, redundancy, and complexity. Java should contain abstract interfaces that can be configured with behaviors and tuned to specific domain concerns. The Microsoft .NET team has taken these architecture principles to heart in LINQ and Windows Communication Foundation. LINQ encompasses language-integrated query, set, and transform operations spanning objects, relational, XML and other forms of data. IBM is working on Project Zero to *simplify* web application development. The JCP collective needs to re-align their mindset and stop the sprawl by embracing composition.
Hopefully, efforts such as JSR 299 that propose to ‘unify the JSF managed bean component model with the EJB component model’ will move forward within the JCP. The JCP should simplify the numerous, overlapping, sprawling models and APIs presented by the Java platform. Developers should not have to live, work, and play in a confusing, sprawling platform. JSR 225 is in a public comment period. To improve developer quality of life, we should speak up against JavaLand's suburban sprawl and demand zoning changes.