On Wed, 17 Jun 2015 22:59:18 +0200, "Markus KARG" <markus@headcrashing.eu>
wrote:
>>I just realized it might actually work: some (maybe all) methods added
in
> the JDBC API for Java 8 were added as default interface methods (with an
> implementation that throws UnsupportedOperationException), so
compilation
> would succeed for org.postgresql.jdbc4.PreparedStatement without having
an
> implementation for the new methods.
>
> Yay, seems you finally noticed we guys at the Java EE EGs are not so
dumb
> as people might think! Honestly, what do you think what we actually
> invented default methods for if not for this case...? ;-)
It still doesn't solve the problem if you actually have an implementation
of that method in your class, which was the starting point of the
discussion as I saw it.
>>You'd still need reflection or an other trick to decide based on the
Java
> version which classes (Statement, PreparedStatement, ResultSet, etc) to
> instantiate.
>
> Only in case of one single driver name and not wanting to provide a
> property telling the JDBC version. Also not in case of separate driver
> names like "Jdbc3Driver". In fact I do not see any difference in
providing
> a list of separate downloads compared to a list of separate driver
names.
It is a problem (although solvable), because JDBC 4 driver loading
requires you to provide a META-INF/services/java.sql.Driver file that
declares the driver(s) provided by the jar. This means that the driver it
declares must be loadable in all JVMs. This means that you either need to
provide a single driver that handles the differences, or you need to have
multiple drivers and ensure that the JDBC4 driver refuses to create
connections if the JDBC 4.1 or 4.2 driver is also loaded.
It will also make things harder for tools that want to load your driver
directly (instead of going through DriverManager).
Mark
