On Wed, 17 Jun 2015 13:52:52 +0200, Mark Rotteveel <mark@lawinegevaar.nl>
wrote:
> That is almost what PostgreSQL uses now, but this is not going to work
if
> you compile with Java 8 and assume that
> org.postgresql.jdbc4.PreparedStatement would then also be new-able when
the
> same jar is used under Java 6 or 7, because
> org.postgresql.jdbc4.PreparedStatement would need to be abstract at
compile
> time as it doesn't contain the methods required by the Java 8 (JDBC 4.2)
> API during compilation.
>
> So getting this to work would need some form of reflection (to get the
> right type at runtime based on the Java version), some preprocessing (as
> done currently) to get around the compilation problem or some byte code
> generation/modification to "unabstract"
> org.postgresql.jdbc4.PreparedStatement after compilation, or some form
of
> tiered compilation (where the org.postgresql.jdbc4.PreparedStatement is
> compiled with Java 7, and org.postgresql.jdbc42.PreparedStatement with
Java
> 8; this might be more complex than the existing solution.
>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
thinkwhat we actually invented default methods for if not for this case...? ;-)
>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
ofseparate driver names like "Jdbc3Driver". In fact I do not see any difference in providing a list of separate
downloadscompared to a list of separate driver names.