On Wed, 17 Jun 2015 14:17:51 +0300, Vladimir Sitnikov
<sitnikov.vladimir@gmail.com> wrote:
>>We're going to need some kind of preprocessing step to handle things
like
>>this.
>
> Sehrope, Marr, sorry, I do not follow you.
> I do not see how you prove preprocessing is required.
I was talking about the situation where you have a single implementation
of the interfaces, but even the way of working below has its problems.
> For instance,
>
> org.postgresql.jdbc42.PreparedStatement extends
> org.postgresql.jdbc4.PreparedStatement {
> public setObject(int parameterIndex, Object x, SQLType targetSqlType)
{
> ...
> }
> }
>
> It does not require "reflection, proxies, byte code generation", etc,
etc.
> It is just a simple "extends".
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.
Mark