JDBC Innovation in JDK 6 Wie man hier nachlesen kann, wird uns JDK 6 einige neue SQLExceptions geben. Das ist erstmal gut. Leider sind die SQLRuntimeExceptions, die mal geplant waren, inzwischen wieder aus der Spezifikation verloren gegangen. Das ist auch nicht wirklich verwunderlich, weil man durch diese Exceptions das Problem hatte, dass auf der einen Seite die checked SQLException steht, die man fangen muss, und auf der anderen Seite die unchecked SQLRuntimeException, die man nicht unbedingt fangen muss - das macht das Leben nur bedingt einfacher. Grundsätzlich sollten technische Exceptions aber RuntimeExceptions sein, weil man sonst die Anwendung dazu zwingt, auf technische Fehler zu reagieren, was sie nur in Ausnahmefällen kann. RuntimeExceptions sind besser geeignet, weil man sie auch in einen generischen Exception-Handler behandeln lassen kann, der z.B. wegen NullPointExceptions sowieso da sein sollte.

Dafür sind die Exceptions bei JDBC jetzt also genauer ausdifferenziert - wenn die Treiber denn mitmachen. Leider betriffft das nur JDBC, wenn man also mit Hibernate auf die Datenbank zugreift, bekommt man für dieselbe Fehler-Situation eine andere Exception.

Letztendlich kommt auch der zitierte Artikel zu dem Schluß, dass man dennoch Spring nutzen sollte. Warum? Weil

• Die Exceptions RuntimeExceptions sind


• Sie bei jeder Persistenz-API (Hibernate, JDBC...) gleich sind


• Außerdem eine Integration verschiedener Persistenz-APIs in einer Transaktion möglich sind

Und dann gibt es noch Dinge wie NamedParameterJdbcTemplate die das Leben weiter vereinfachen.

JDBC ohne Spring ist einfach keine gute Idee. Die interessante Frage ist nun, was das für JDBC heißt. Meiner Ansicht nach kann im JDBC-Standard selbst kaum noch sinnvolle Arbeit geleistet werden. Wenn man sowieso nicht mit JDBC direkt arbeiten kann, sondern eine Abstraktion wie Spring JdcbTemplate verwendet, macht eine Verbesserung der APIs keinen Sinn. Die neuen Features von JDBC 4 zur automatischen Umwandlung von Anfrage-Ergebnissen in Objekte, die eher in die Richtung von iBATIS gehen, sehe ich daher eher kritisch. Bei den Exceptions kann man wegen der Abwärtkompatibilität nicht viel machen, RuntimeExceptions zusätzlich einzubauen ist kaum sinnvoll. Der große Erfolg von JDBC ist, dass es JDBC-Treiber für praktisch alle Datenbanken gibt und JDBC daher eine gute Basis für all die anderen Java-Persistenzlösungen bieten kann.  ¶ 14:02