Re: Pre-processing during build - Mailing list pgsql-jdbc

Sorry but you're wrong here.

Vladimir's example was invalid. See https://gist.github.com/mkarg/88a89ae0dbffcfb7543e instead.

Resolution will not fail. Even early static resolution won't. Check again the chapter of JLS about the critera to throw
thelisted exceptions. None of them is met with the corrected example
https://gist.github.com/mkarg/88a89ae0dbffcfb7543e.

The direct example will NOT fail on Java 7 as the method is not changed, but added. The original method is still in
place.Both methods exist at the same time and differ by signature, hence the linker of the old program finds the old
methodin the new class. No problem at all. 

The indirect example will NOT fail on Java 7 as a JRE 7 client will never pass in an instance of a JRE 8 type (how
shouldeven know of its existence?), and the Java 6 machine executing the invoked method will never INSTANTIATE that
typeso it will not fail. No problem at all. 

Still should work. You'd possibly like to set up a proof using the corrected example
https://gist.github.com/mkarg/88a89ae0dbffcfb7543e.:-) 

Regards
-Markus

-----Original Message-----
From: Mark Rotteveel [mailto:mark@lawinegevaar.nl]
Sent: Mittwoch, 17. Juni 2015 09:18
To: Markus KARG
Subject: RE: [JDBC] Pre-processing during build

On Tue, 16 Jun 2015 21:35:33 +0200, "Markus KARG" <markus@headcrashing.eu>
wrote:
> On Mon, 15 Jun 2015 23:59:45 +0200, "Markus KARG"
<markus@headcrashing.eu>
> wrote:
>> For Java 6 and 7 it would be possible to use the same codebase (if you
> ignore certain types iirc), but for Java 8 you need a separate library
due
> to the introduction of the SQLType interface. And if you fully support
JDBC
> 4.2, you also need the classes from java.time.
>
> Actually I doubt that truely. The idea is NOT to support JDBC42 on Java
6.
> The idea is that Java 6 loads our JAR and calls JDBC4 methods. The fact
> that the same JAR also contains Java 8 types like java.time or the new
> SQLType is invisible to the JRE 6 client application, as that one is
> written against JDBC4, hence does neither INSTANTIATE that types NOR
> invokes the methods using them as parameters!

Vladimir already demonstrated one problem, at least when using reflection
(which is not atypical with a lot of tools that use JDBC and with
connections pools). And I already pointed at the resolution phase as
described in the JLS that might happen at classloading time.

>> JDBC APIs themselves are not backwards compatible (ie: they introduce
new
> types in the signature, or require you to handle new types in existing
> methods), the API is only backwards compatible from the perspective of
the
> user.
>
> I think that's pretty enough. Nobody forces is to use Oracle's JARs. The
> driver just has to fulil the API towards the client application. That's
why
> it's called an API (not SPI). Can you please make an example what API is
> incompatible between JDBC4 and JDBC42?

An example of direct API incompatibility, use of a type new in Java 8
(SQLType):
ResultSet.updateObject(int columnIndex, Object x, SQLType targetSqlType)
http://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#updateObject-int-java.lang.Object-java.sql.SQLType-

An example of indirect API incompatibility: requirement to support
java.time types (added in Java 8) in get/set/updateObject, although that
can be worked around.

Mark