Question

I am developing a Java Desktop Application but have some confusions in choosing a technology for my persistence layer.

Till now, I have been using JDBC for DB operations. Now, Recently I learnt Hibernate and JPA but still I am a novice on these technologies.

Now my question is What to use for my Java Desktop Application from the following?

• JPA

• Hibernate

• JDBC

• DAO

• any other suggestion from you…

I know that there is no best choice from them and it totally depends on the complexity and the requeirements of the project so below are the requirements of my project

1. It’s not a complex application. It contains only 5 tables (and 5 entities)
2. I wan’t to make my code flexible so that I can change the database later easily
3. The size of the application should remain as small as possible as I will have to distribute it to my clients through internet.
4. It must be free to use in commercial development and distribution.

==================================== EDITED =======================================

On the basis of the below answers, I would like to go with JPA so as to prevent myself from writing vendor-specific SQL code.

But I have some problems in JPA which are mentioned at Java Persistence API

Answer 1

Here’s my take:

• JPA: Agnostic way to do Java persistence without coupling your clients to Hibernate, TopLink, etc.
• Hibernate: Good choice if you have an object model to map to.
• JDBC: All Java persistence is built on this. Lowest level
• DAO: More of a pattern than a technology; CRUD operation interface.
• iBatis: Halfway between JDBC (raw SQL) and Hibernate (ORM).
• JDO: Java Data Objects, which is another specification for Java persistence. (e.g., Apache JDO)

It’s not a complex application. It contains only 5 tables (and 5
entities)

Any of these will work, but JDBC will be the simplest. All the others are built on top of JDBC.

I want to make my code flexible so that I can change the database later
easily

Schema changes will have similar effects in all technologies.

The size of the application should remain as small as possible as I will
have to distribute it to my clients
through internet.

Using JPA or Hibernate will require JARs that will add to the size of your deployment. JDBC will minimize this.

It must be free to use in commercial development and distribution.

See licenses of all technologies. Shouldn’t be a problem with any of them.

FYI: It’s possible to write a generic DAO interface:

package persistence;

import java.io.Serializable;
import java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    T find(K id);
    List<T> find();
    List<T> find(T example);
    List<T> find(String queryName, String [] paramNames, Object [] bindValues);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}

If your objects map 1:1 with your five tables, I’d say that JPA is overkill squared.

Is your app currently on the order of 3MB JAR? If no, then Hibernate or JPA will more than double the size. You can quantify exactly how much. And there’s more than one JAR, because they both have dependencies.

YAGNI says that you should keep it simple. It’s five tables!

Changing vendor, if you do it properly, means switching a JDBC driver JAR, changing the driver class name, and adding the new connection URL – which you have to do no matter what technology you pick.

I find that databases don’t change that radically. You’ll change the schema, but the entire vendor? Not likely, especially if you have several clients. It’ll be a major inconvenience to make a user base switch databases.

Which one were you planning to ship with? HSQL or something that will require an installation like MySQL? That’s a more pertinent concern.