Your program's business objects and database want to be different things
How little things change, it seems. In the mid 90's, at my first really serious programming jobs, one of the first things we did was to create our business objects and start developing "DB" classes to persist those objects to a relational database and populate them from database queries. Back in the Java 1.1 days, before the bounty of free frameworks to do that kind of thing for you, it meant writing lots of SQL code by hand, stitching together strings for
SELECT statements with fields from the user's query, trying to santitize it so that funny input wouldn't break the query string, etc. This approach had lots of drawbacks: not only was it labor-intensive to get working in the first place and somewhat brittle, it was also highly resistant to needed updates in the business objects (something that's inevitable in a startup as plans change), and subclassing the business objects to add new fields made for even more fun.
And today... well, we have frameworks to do this for us, from EJB to Hibernate, but the underlying problem is the same: objects and database are based on fundamentally different concepts, and bridging the two can be a difficult pursuit. And short of abandoning one side or the other -- using an object database, or using shallow, row-like data models in your application -- it's a challenge that many of us will continue to have to deal with.
Writing in ACM Queue magazine, Craig Russell takes a look at Bridging the Object-Relational Divide, explaining the problems it addresses and why it's so frequently talked about, noting that "in modern applications, however, the amount of effort devoted to persistence can dominate the cost of a project, and using ORM tools can significantly reduce this cost."
"ORM can provide significant improvements in programmer productivity, application quality, and maintainability. One of the most important ways this is achieved is through separation of concerns: separating the behavior of the domain object model from the access of the data from the database. Using a standard API allows the choice of implementation to be a late decision, providing more time for evaluation of alternative mapping and database technologies."
Also in Java Today, The Aquarium and Ed Burns note that Mojarra lead developer Ryan Lubke has been posting a series of blogs on the new features of JSF 2.0. The series so far covers Packaging / Project Staging, Resources, Resource APIs, Resources and EL, Publish/Subscribe Event System, and Resource Re-location.
In the a SDN article, Carol Zhang discusses How Java Plays With Scripting Languages. "Java and scripting languages are not mutually exclusive. On the contrary, they are complementary and can play together in many scenarios. Combining scripting languages with the Java platform provides developers an opportunity to leverage the abilities of both environments. You can continue to use scripting languages for all the reasons you already have, and you can use the powerful Java class library to extend the abilities of those languages."
In today's Weblogs, Kito D.