SQLJ Karl seems to promote SQLJ. I have a strong feeling against this technology, because it’s a wild and dreaded mix of SQL and Java code. So, to back up this statement, let’s have a look at advantages and disadvantages:
Advantages – compile time checks.
- you have to learn SQLJ.
- you embed your SQL code(which is not exactly sql) directly into the application.
- you intermingle mapping logic with connectivity logic.
CMP and JDO don’t that appeal to me also. Although these both technologies are proven in the battlefield and showed their maturity, they also have a certain disadvantages. Of course, it’s also a learning curve. Then, it can be very tricky to track WHAT exactly is happening behind the scenes: what sql queries are getting issued to the database, when, how often. Unfortunately I had no chance to play with CMP and JDO in WebAS, so I’d ask other people who did to speak their mind.
JDBC. Last in the list, but not last in developers’ arsenal. Combination JDBC + Open SQL seems to me the most powerful today. Unfortunately here we have to introduce JDBC connectivity code into our applications. J2EE zealots solve it with DAOs(Data Access Objects), home-built frameworks and! with open source community frameworks. An example of such community framework is Spring framework. It does a lot of different interesting things and one of them is JDBC abstraction.
I specially omitted stored procedures here, because it’s currently not supported on the Open SQL level. Though, this mechanism is extremely powerful and fast and I really miss it.
So, to make a conclusion…I guess it’d be an interesting undertaking to make a component, linking Open SQL with Spring JDBC abstraction layer.