Skip to main content

Two Hearts

Posted by editor on June 30, 2008 at 5:20 AM PDT

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. Mann takes a look at job posting data for various Java web frameworks in
JSF Job Stats, Indeed.
"A couple of years ago I posted some job trend graphs from Since then, it's become the hip thing to do. So, in order to remain hip, I figured it was time for an update..."

Jim Driscoll reports JSF 2.0 is getting closer, in
Mojarra's JSF 2.0 EDR1 ships.
"The Mojarra Project is proud to announce the release of the JSF 2.0 EDR1 implementation."

Finally, Satya Komatineni asks
A False ceiling: What is behind that blanket of SOA?
"It is not an uncommon argument in IT, where the thought is to hide everything behind a bus of SOA. Couple that with the hype where once upon a time CORBA solved all problems and then EJBs solved all problems. Now SOA is on the lips of many that probably have never written a line of code. It is difficult to argue with someone who is not a goldsmith that what is glittering is not necessarily gold."

In today's Forums,
perkmobile_pn asks
When will LWUIT source be availible? Post if you would like the same.
"When will the LWUIT project be open source? I ask because it seems like a lot of the chatter on these forums could be better resolved if source was in hand. Additionally, because the line count of the code is small compared to other projects, acclimating themselves to the source would be a relatively fast process."

Fabrizio Giudici clarifies the extent of archiving of dormant projects in
Re: projects summer cleanup under way ...
"Yep, but "archiving" a project just means that it's moved under an "archive" umbrella; for the rest, the URLs, the mailing list and repository still works as usual. This is just a way to tidy up the web pages (they're cleaning up the web, not the repository AFAIU) so the casual navigator will look at the communities and see only active projects."

andrewherron discusses why the JDK 6u10 page says nothing about the Mac in
Re: Mac OS. "Sun don't develop Java for Mac, Apple are 100% responsible for their port (although I believe it's based on the Sun code). Why would 6u10 be any different? There's no need to say "doesn't work on x" when it's never worked on x in the past. They list the platforms that are supported, therefore everything else is not supported."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

Your program's business objects and database want to be different things