Re: Pre-processing during build

The answer is pretty simple: Try it out. :-)

Just compile a JRE 8 class down to byte code level 6 and load it on Java level 7. That's what I proposed. Nothing else. It really bet will work unless you try to INSTANTIATE JRE-only classes, but it should LOAD. And nothing more we need.

From: davecramer(at)gmail(dot)com [mailto:davecramer(at)gmail(dot)com] On Behalf Of Dave Cramer
Sent: Dienstag, 16. Juni 2015 00:54
To: Vladimir Sitnikov
Cc: Markus KARG; List
Subject: Re: [JDBC] Pre-processing during build

I'm wondering if we use the latest JRE to compile but target 1.7 will it use the latest JDBC API, but compile to 1.7 bytecode. Apparently https://github.com/brettwooldridge/HikariCP uses this method; and they have a similar problem

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 15 June 2015 at 18:47, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> wrote:

Marcus,

>Has anybody tried whether it is possible to simply load a JRE8-JDBC42.jar on JRE6?

As you are a fan of JEPs, you might know of
http://openjdk.java.net/jeps/238 : Multi-Version JAR Files
It does not "just work" yet.

Suppose you want implement PreparedStatement(...java.sql.SQLType)
features of JDBC 4.2 (see [1]).
Even if you compile that with target 1.7, JRE 7 might fail to load the
class as it won't be able to validate what that SQLType is. It just
does not exist in JRE7.

As far as I understand, the only manageable way of using "new
features" in "JDK6-7 jars" is to isolate JDK8-using methods to
JDK8-only-loaded classes. For instance, PreparedStatement41.java and
PreparedStatement42.java

[1]: https://docs.oracle.com/javase/8/docs/api/java/sql/PreparedStatement.html#setObject-int-java.lang.Object-java.sql.SQLType-

Vladimir