I did some experiments with JPA, which is a really cool and simple API for entity persistence. In fact, writing an entity bean is as simple as writing a pojo plus adding some single annotations like @Entity and @Id (to identify the PK fields). That's it. Cool. :-)

See this sample code:

 public class MySample {
    private int x;
    public int getX() {
        return this.x;
    public void setX(int x) {
        this.x = x;

Yes, it's just that simple. No more DD needed (but can be optionally added for admin's customizations). And accessing objects is as simple as the following samples showcase:

 EntityManagerFactory emf = Persistence.createEntityManagerFactory("pu1");
 EntityManager em = emf.createEntityManager();
 // INSERT INTO MySample is just as easy as:
 MySample mySample = new MySample();
 mySample.setX(12345); // Alternatively an entity can use @Generated to have an autogenerated PK!
 // SELECT FROM MySample is just as easy as:
 Query q = em.createQuery("SELECT OBJECT(m) FROM MySample m"); // This is not SQL but OOP: All names are getting MAPPED internally!
 for (final MySample aSample : q.getResultList()) {

(Sorry if there are any typos)

Sounds cool? It IS cool!

But then, I compared the performance of such a simple benchmark like the above one to pure JDBC4. Guys, this simplicity really is expensive. I measured that JPA needs ten times longer than pure JDBC4! Why? It's just as easy as this: JPA has a lot of power inside. You can do a real lot of things in one code line that would need ten or twenty code lines in JDBC. I used TPTP (the Eclipse Profiler) to find out what JPA internally works like, and then it was all clear to me. That flexibility must be come from somewhere, and that somewhere is paid by thousands of code lines running even for the most simple SELECT statement.

So what can we learn? JPA is a pretty cool thing since we can write a single annotation instead of 10 or 20 JDBC lines. But we have to take care not to access more data rows than needed, since every data line is 10 times more expensive in terms of CPU power than JDBC is. As with everything, it is a tradeoff between spending time in coding and spending runtime. One must take good care not to write silly code (like the above one: Who actually wants to load all rows from a table without using a WHERE clause to select the needed ones?). If that rule is applied, I think the performance drawbacks will not be a problem in real life applications.