|
Interview: Bruce Tate on the "Politics of Persistence"
by Barry Burd
Barry Burd interviewed Bruce Tate at the No Fluff, Just Stuff Java Symposium. Bruce is the author of several books, including Bitter Java, Bitter EJB (with Mike Clark, Bob Lee, and Patrick Linskey) and the Jolt-winning Better, Faster, Lighter Java (with Justin Gehtland). In this interview, Bruce compares some of the major Java persistence frameworks.
Barry Burd (BB): Please introduce yourself to the Java Boutique readers.
Bruce Tate (BT): I'm a father, kayaker, and mountain biker from Austin Texas. My business, J2Life, focuses on lightweight development in Java and Ruby. My core competencies include design reviews in which I talk to customers, read code, and interview developers. I help the customer understand what's working and what's not working.
I also teach symposiums with No Fluff, Just Stuff. These are weekend symposiums with a little bit less marketing than JavaOne, and a lot less cost.
What do you tell a customer who's comparing persistence frameworks?
Comparing Persistence Frameworks
BB: What do you tell a customer who's comparing persistence frameworks?
BT: I typically tell a customer to start with the simplest possible solution. The simplest is JDBC, but there are a couple of frameworks that wrap JDBC. The most important of the JDBC-wrapping frameworks called iBATIS (created by Clinton Begin of ThoughtWorks, which is Martin Fowler's company). The iBATIS framework differs from the typical object relational mapping framework in that you're mapping to the results of an SQL query instead of a relational schema. So iBATIS is very good for stripping away a lot of the junk that you deal with in JDBC frameworks. The iBATIS framework is good for people who know a lot about SQL but not quite so much about Java.
If iBATIS isn't enough, I try Hibernate. I like Hibernate because it's free and it has strong mapping support and excellent support in the open source community.
If Hibernate isn't enough, I move to something like JDO. My favorite JDO implementation is the SolarMetric Kodo product. I like Kodo JDO because it has the best mapping in the industry and the best manageability of the major persistence frameworks in the industry that I've tried.
Now there's also the emerging EJB3 standard—JSR 220. EJB3 is a redefinition of persistence pretty much from the ground up. With EJB3, you're starting to see a meeting of the minds between the EJB expert group the JDO expert group. The JDO expert group has a head start, so they've got more specification together. Of course, JDO has had nowhere near the political clout that the EJB group has.
I think the JSR 220 long-term vision is a merger of EJB and JDO into a combined persistence specification. So you're likely to see a little bit of the strengths of both platforms but, frankly, some weaknesses of both.
BB: What weaknesses do you have in mind?
BT: For JDO, the weakness is clearly political. The JDO group has never had the political clout of the major EJB players. And JDO has never had the customer base that EJB containers have shared.
On the EJB side, the EJB specification doesn't have the full power of the JDO mapping framework. EJB doesn't have fetch groups and some of the finer details that define how to make a request be lazy or eager. With JDO fetch groups, you can package a strategy not just for an entire application, but also for individual scenarios.
BB: Is it possible to mix-and-match the features of say JDO, Hibernate, and EJB to get a sufficiently simple "Swiss Army Knife" persistence framework?
BT: That's the intent of some JDO persistence solution providers. I talked to Neelan Choksi after he presented at JavaOne (Neelan is the president of SolarMetric). He said that SolarMetric's intent is to offer a framework that supports both EJB and JDO persistence, so that you can execute an EJB query language query within a JDO persistence manager.
BB: Do you think the mix-and-match approach can succeed? Can we have a persistence framework that's all things to all people?
BT: With the Spring framework, you can share a data source and some caching across iBATIS and Hibernate. You can have an iBATIS query and a Hibernate Query Language (HQL) query run side-by-side within the same transaction. You also have the ability to run SQL queries against a JDO implementation, and some JDO vendors are making noise about supporting Hibernate HQL queries. Essentially, you're seeing a mix-and-match of features today.
Different Tools for Different Jobs
BB: You're a big fan of dynamic languages such as Ruby and SmallTalk. Are ActiveRecord and the dynamic-language persistence frameworks fundamentally incompatible with things like EJB and JDO?
BT: ActiveRecord is a different design pattern. The Java design pattern handles persistence completely transparently. In the Java space, you would say session.saveAllTheObjects in a particular bucket. In the ActiveRecord world, you would say personObjectNamed(BruceTate).saveYourself. It's a subtle difference but it's an important one.
The dynamic languages help the ActiveRecord design pattern (at least the ActiveRecord implementation within Ruby). You can say: "I want this empty wrapper to point to a class called Person and I want to point this class called Person to a table called people." Ruby can look at the name of the class through reflection, and map the Person string to a string called people. Then it can look at a database table called people and dynamically add each column in the database as a property in the object model. Then, through meta-programming, you can also add methods to do your CRUD operations—creates, reads, updates, and deletes.
BB: You mention meta-programming. How does meta-programming vary from one framework to another?
BT: Meta-programming is having programs write programs. When you deploy an EJB application, the container actually does a code generation step. JDO uses bytecode enhancement which is basically code generation after an object has already been compiled (either before runtime or after runtime).
You can also use reflective techniques. You can use proxies and interceptors. You can put some of those techniques together with aspect-oriented programming, and you can add annotations to that mix.
BB: Which of these techniques do you favor?
BT: They are different tools for different jobs, so you might mix-and-match the techniques. For example, consider the Java 5 feature called annotations. Java 5 uses reflection to look inside an object and see the annotation values. Java 5 uses bytecode enhancement to push the annotation's parameters into the object. Different techniques are used for different problems.
I think that annotations and aspect-oriented programming are great ideas. Annotations might be very useful to make something transactional. But annotations and aspect-oriented programming will be misused over time. With annotations often we mix database object relational mapping data in the annotations. Sometimes that's not the best of ideas, because you often want to separate the object and schema from the mapping. We accumulate technology before we accumulate the wisdom to use the technology.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
