Consider the following (familiar) scenario: Your company currently writes a client-server application, and has 300 clients connecting to a main server. Every time you change your client (bug fixes, enhancement, etc.), you must notify every user to get a copy of the new code. Therefore, those changes are bundled together, and “releases” are made when the changes are deemed significant enough.

There are several problems with this system. First, there is a significant lag between when a change is made and when your customer receives it. Second, cutting releases and distributing them is time-consuming and expensive. And finally, you end up supporting every version of the client that is currently being run—or you tell your customers to upgrade—which they love to hear.

Java can be used to solve these problems, by using what is called a class repository—not to be confused with an Object Request Broker (ORB) which is completely different. Because Java's compiled .class files are portable and can be loaded dynamically at run time, the following scenario becomes possible:

You still have 300 clients connecting to a main server. However, when you change part of your code, you simply update a database (class repository) with the new .class file and modification date. When the client starts, it asks the server, “What classes have changed since I last accessed?” The server then checks the repository, and returns a list of class names. When (and if) the client needs one of those classes, it simply receives it from the server, storing it locally for future use, and loads it.

This system solves all of the problems above. However, there is no easy way to access a database through Java. Sun has released jdbc, a specification based on ODBC, and many database providers have endorsed it, but as of the time of this writing, no implementations are available.

This, then, became the motivation for Jgres: to write a wrapper package for libpq that would allow easy access to a Postgres95 database.