From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Sehrope Sarkuni Sent: Mittwoch, 17. Juni 2015 13:05 To: Dave Cramer Cc: Mark Rotteveel; List Subject: Re: [JDBC] Pre-processing during build
On Wed, Jun 17, 2015 at 6:15 AM, Dave Cramer <pg@fastcrypt.com> wrote:
I'm not sure this is a great example as Optional itself is a java 8 construct.
Either way Spring is able to do this, as are others?
The approach used by Spring won't work for the JDBC driver. The crux of the issue is that the newest version of the JDBC spec include Java 8 types in method signatures of public interfaces that exist in Java . Spring doesn't do that.
There's no way to make that work when a public interface exposes classes that won't exist on the run time. It may have been possible with older upgrades to the JDBC spec (ex: 4 to 4.1) as there weren't any JDK 1.7-only classes used in methods signatures of existing public interfaces. Compiling with an older bytecode target would allow and older JDK to simply ignore those methods as they would not be part of the public signature.
In JDBC 4.2 that's not true though. For example the JDBC 4.2 PreparedStatement class has a new setObject(...) that uses a Java 8 only class:
That method signature can't appear in a driver that is going to be used in JDK 6 or 7. There's no way to hide it internally as it's part of the public signature.
We're going to need some kind of preprocessing step to handle things like this.
