On Mon, 15 Jun 2015 23:59:45 +0200, "Markus KARG" <markus@headcrashing.eu>
wrote:
> If it would be up to me, I would try to get rid of pre-processing if any
> possible, since it is a real p.i.t.a., as long as we can find a
different
> solution to provide the same number of supported JDKs and JDBC versions.
>
> The question is: How? Possibly by simply using "JRE8-JDBC42.jar" ALWAYS?
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.
> Has anybody tried whether it is possible to simply load a
JRE8-JDBC42.jar
> on
> JRE6? I mean, not to actually invoke the new JDBC42 APIs, just to load
the
> JAR and invoke the JDBC3 APIs only for example. The APIs themselved are
> backwards compatible, and as long as we don't invoke the new APIs, no
> ClassNotFound should happen (AFAIK the JRE loads classes only at first
> actual instantiation, but not simply because it is contained in a loaded
> .class file as a parameter). I mean, as long as we do not use JRE8-only
> APIs
> inside the Driver, and as long as we don't write the .class files in
JRE8
> byte code, certainly.
>
> Or did I miss something in this theoretical approach?
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.
Mark