In Relation To

There's been a certain amount of noise recently surrounding simple JDBC frameworks like iBATIS. I've liked the idea of iBATIS myself, for use in applications which don't need an object-oriented domain model, and don't work with deep graphs of associated entities in a single transaction. A JDBC framework also makes good sense if you are working with some kind of insane legacy database; ORM solutions tend to assume that associations are represented as nice clean foreign keys with proper referential integrity constraints (Hibernate3 much less so than Hibernate 2.x).

Just had an interesting discussion on ejb3-feedback@sun.com, started by David Cherryhomes, which saw me stupidly insistingthat something can't be done when in fact, now that I think about it, /I realize I've actually done it before/, and that even the Hibernate AdminApp example uses this pattern!

Another major change in Hibernate3 is the evolution to use an event and listener paradigm as its core processing model. This allows very fine-grained hooks into Hibernate internal processing in response to external, application initiated requests. It even allows customization or complete over-riding of how Hibernate reacts to these requests. It really serves as an expansion of what Hibernate tried to acheive though the earlier Interceptor, Lifecycle, and Validatable interafaces.

Hibernate3 adds the ability to pre-define filter criteria and attach those filters at both a class and a collection level. What's a pre-defined filter criteria? Well, it's the ability to define a limit clause very similiar to the existing where attribute available on the class and various collection elements. Except these filter conditions can be parameterized! The application can then make the decision at runtime whether given filters should be enabled and what their parameter values should be.

I just cleaned up some of my files and found this snapshot in one of my folders. I made it two weeks ago, as I finally had time to install Oracle 10g. I remember how I was shaking my head in desperation as I realized what they had done. Let me explain.

Simple is a seductive notion. We all want to make things simple. But when we talk about software, simple could mean at least two different things.

Cedric and Bill have proposed solutions. My preference is basically similar to Bill's, but here's how I would write it:

This item is a prediction about the future. Predicting the future is a dangerous business, and exposes the author to ridicule in both the future and present. Nevertheless, articulating a /nice/ vision of the future can help bring about that future.

Now that the EJB 3.0 early draft is out there, it's definitely time to move on from all the recent politics, and start thinking about what we can actually /do/ with this stuff. EJB is the only Java standard which addresses server-side /business logic/, and is thus central to J2EE. The EJB spec committee recognizes that EJB has fallen short of achieving some of its ambitious goals, and is in need of an overhaul. This overhaul has focused very much upon ease of use, primarily via simplification of the requirements upon bean implementors. However, the spec committe also identified a number of critical functional enhancements that facilitate ease of use and the elimination of certain J2EE anti-patterns.

Another blogger, who will remain unmentionable, is upset that some of the guys at JBoss are beginning to throw the term AO around. According to him, the AOP community is just terribly attached to their P, and quite concerned that JBoss might be about to dominate the world with their P-less aspects.