I enjoy the flexibility of Java. I think it's wonderful I can switch out application servers and databases without much work. I can even switch in and out classes at runtime by just extending ClassLoader. You can even run Java on everything from large servers to cell phones, but is your code flexible enough to use databases ranging from Oracle to Nokia?

One of my current projects requires such flexibility. The same application needs to run on large production servers, disconnected laptops for the sales force, and a custom micro device. The production system accesses data using an Oracle Spatial database while the sales force accesses a subset of data via files and the micro device uses a very small database without spatial features. The solution for this flexibility is a Data Access Object (DAO) defined by an environment variable in a ejb-jar.xml or web.xml file.

SegmentsDAO is an example DAO that I'll use to explain this solution. It includes a method that takes a coverage rectangle and returns all the streets covered by it. The code looks like this.

public interface SegmentsDAO {
    List getSegments(double x, double y, double width, double height) throws MapDAOException;
}

Each method in the DAO throws a generic xxxDAOException. This way the rest of the application only needs to worry about xxxDAOExceptions. It doesn't matter if one implementation calls a database that throws SQLExceptions and another reads a file that throws IOExceptions; they are both wrapped in a xxxDAOException.

The SegmentsDAO sits behind a session façade, or possibly a servlet that uses an environment variable to determine what SegmentsDAO implementation to use. The code looks like this.

public class MapManager implements SessionBean {
    private SegmentsDAO segmentsDAO;

    ...

    public void setSessionContext(SessionContext sessionContext) {
        this.sessionContext = sessionContext;
        Context context = new InitialContext();
        try {
            String segmentsDAOClassname =
                (String)context.lookup("java:comp/env/segmentsDAOClassname");
            SegmentsDAO = (SegmentsDAO)Class.forName(segmentsDAOClassname).newInstance();
        } catch (...) {
            throw new EJBException(...);
        }
    }

    public List getSegments(double x, double y, double width, double height) throws MapException {
        return segmentsDAO.getSegments(x, y, width, height);
    }

    ...
}

In my ejb-jar.xml file I have a block that looks like this.

<env-entry>
    <env-entry-name>segmentsDAOClassname</env-entry-name>
    <env-entry-value>%segmentsDAOClassname%</env-entry-value>
    <env-entry-type>java.lang.String</env-entry-type>
</env-entry>

This way if the installation is for a sales person I can have Ant replace %segmentsDAOClassname% with com.company.map.dao.SegmentsFileDAO or com.company.map.dao.SegmentsOraSoDAO for the production system.

I use this solution whenever I have to deal with code that requires additional flexibility. A nice side benefit is the ability to do quick vendor or implementation comparisons. I recently used this solution to test Java mapping components from various vendors. I could stress test the component within my application, knowing that any differences in performance were attributable to the component. Remember requirements and vendors will change, make sure your code can.