0

I'm trying to sort out the relationship between a JDK version and a JDBC driver type - in the context of implementing some program that uses the driver.

Using an example to explain my question: given a Java 8 runtime, I know that I can use try-with-resource to automatically clean up database connection and related resources. However, do I also need to make sure that the JDBC driver installed alongside my program is of type 4.1 or higher? what will happen if the database vendor only supplies type 3 or 2 driver? will I get a runtime error? or will it silently fail to clean up the resources? or will it work just fine?

try-with-resource is just an example - my question isn't specifically related to that, but is more around what are the consideration one should take into account when going about developing a program to access some database using JDBC? should I go by the driver type first and then infer from it which java features I can use? should I just go by the java version and things will magically work well?

Legato
  • 1,031
  • 1
  • 9
  • 20

1 Answers1

0

Firstly, here's how to use try-with-resources with a jdbc Connection and PreparedStatement.

How should I use try-with-resources with JDBC?

Now with regards to driver type, unless you are dealing with a weird database that hasn't been maintained for the last 10 years, you can pretty much rely on having a type 3 or type 4 driver available as the latest jdbc driver download.

You won't get a runtime error if vendor supplies a type 3 or type 2 driver, unless you try to use a feature that for some reason isn't implemented (you'll get some sort of "Not Implemented" RuntimeException). But in my 15 years of java I have never seen a database driver throw a runtime error because of this, so I wouldn't worry ;)

This is getting broad now, but for designing a program with JDBC, you really shouldn't need to pay much attention to the driver. In theory, you can swap out your SQLServer driver for an Oracle driver - there may be some differences in dialect but it otherwise should just work. In general, things just should work magically, given you are using a modern relational database.

Lastly, you could look at using a "database connection pool". Some common ones are commons-dbcp and hikariCP.

Community
  • 1
  • 1
vikingsteve
  • 38,481
  • 23
  • 112
  • 156
  • Thanks vikingsteve! how about JDBC4 drivers implementing SPI? In such cases my application doesn't need to use class.forName(driver-class-name) where types less than 4 require explicit loading of the driver? I know that I can *always* specify class.forName() just to be safe, but it is something that I need to pay attention to and specifically relates to driver type right? unless I'm getting it wrong, do you know of any other such differences? – Legato Jan 19 '16 at 08:38
  • I'm not sure what SPI means here, though If you are dealing with jdbc classes directly, `DataSource` and `Connection` and so on, using `class.forName(...)` forces the classloader to load the driver, and it's the standard mechanism for JDBC. If you get to the point of using a `dbcp`, you can define the datasource as a spring bean in xml, and specify `driverClassName` directly there (instead of using `forName`), like the very top part of the code in the answer here: http://stackoverflow.com/questions/27102265/how-to-configure-hibernate-spring-and-apache-dbcp-for-connection-pooling – vikingsteve Jan 19 '16 at 08:52