I am working on a stand-alone server application, so I don't have JNDI services. I am creating a simple connection pooling class (which I've done in the past), and I want to avoid locking in to a particular driver class. What's troubling me is the push to DataSource. I like the concept, and it's easy to use. The problem is, the interface is so limited, I don't see any way of using it in a generic manner. Within the Java Database, ClientDataSource and EmbeddedDataSource having nothing in common but the DataSource interface.
My questions are
1. Is DriverManager use antiquated, as some posts (not here) suggest?
2. How does a JNDI provider create connection, under the covers?
Ok first off, you never need to hardcode anything, you can always lookup which drivers/connection to use in a properties file often consisting of 4 items: driver class, URL, username, password.
Second, what exactly are you worried about locking into? JDBC is an interface, with the implementation handled by the driver. In other words, all JDBC code should run on all databases, granted that doesn't mean all queries within JDBC statements will run on all databases, but it would be a wonderful world were that the case.
Lastly, I wouldn't call DriverManager antiquated really, one of the things you might be missing is that a lot of servers actually setup "connection pools" in JNDI instead of a single connection. There may be a dozen reusable connections in the pool that the server manages for you. This is a huge gain in multi-threading environments.