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.
You'd still need reflection or an other trick to decide based on the Java
version which classes (Statement, PreparedStatement, ResultSet, etc) to
instantiate.
Mark