On 26-11-2015 18:03, Adam Brightwell wrote: >> Our bigger problem is to figure out how to have JDK 1.6, 1.7, and 1.8 and >> ... all supported by one codebase > > Isn't that what the '-source' and '-target' flags for javac are meant > to help solve?
That only helps if you are compiling the same software for different Java versions (and then it would suffice to just target Java 6, as Java 6 bytecode can also be run on newer Java versions).
Also, if you use any new feature in the API, then compiling this way will lead to a false sense of security as a Java 7 compiler set to -source and -target 1.6 will **not** detect that you used new classes or methods (unless you explicitly specify a bootclasspath that points to the Java 6 runtime classes).
The main problem however is that Java 6 is JDBC 4.0, Java 7 JDBC 4.1 and Java 8 JDBC 4.2. Each new version added new methods and requirements. If I recall correctly it should be possible to compile JDBC 4.1 compliant code with Java 6 (there might be some edge cases), however JDBC 4.2 added a number of new methods that take the SQLType interface, which was added in Java 8. On top of that, JDBC 4.2 compliance requires implementation of java.time support on get/setObject in PreparedStatement and ResultSet.
this is the real problem, thanks for the reminder.
Java.time was also introduced in Java 8.
new methods would be OK, as older JDBC versions would never call them, but the import for Java.time fails
This makes it impossible to compile the same code for Java 6 and Java 8. You need to do some form of preprocessing, or selecting/combining version dependent sourcetrees.