proxy7test

gistfile1.java

import java.time.Duration;
import java.util.Optional;
import java.lang.reflect.*;
 
public class Jre7Test {
	public static interface I7 {
		public void say(String greeting);
	}

	public static interface I8 extends I7 {
		public Optional<Duration> optional(java.time.Duration duration);
		public void say(String greeting);
	}

	public static class MyClass7 implements I7 {
		public void say(String greeting) {
			System.out.println("J7 says: " + greeting);
		}
	}

	public static class MyClass8 extends MyClass7 implements I8 {
		public Optional<Duration> optional(java.time.Duration duration) {
			return Optional.of(duration);
		}
		public void say(String greeting) {
			System.out.println("J8 says: " + greeting);
		}
	}
 
	public static void main(String[] args) {
		InvocationHandler handler = new InvocationHandler() {
			public Object invoke(Object proxy, Method method, Object[] args) {
				try {
					return method.invoke(new MyClass8(), args);
				} catch (Exception e) {
					return new RuntimeException(e);
				}
			}
		};
		I7 proxy = (I7) Proxy.newProxyInstance(Jre7Test.class.getClassLoader(), new Class[] { I7.class } , handler);
		proxy.say("Hello from proxy");
		proxy.getClass().getMethods();
	}
}

gistfile2.txt

"C:\Program Files\Java\jdk1.8.0_45\bin\javac.exe" -source 1.7 -target 1.7 Jre7Test.java
warning: [options] bootstrap class path not set in conjunction with -source 1.7
1 warning

"C:\Program Files\Java\jre7\bin\java.exe" Jre7Test
J7 says: Hello from proxy

The above source code proofs that it is pretty safe to contain a Java 8 class in a code that is executed in Java 7, as long as you do not explicity use the Java 8 class. At runtime, a simple check could be done whether Java 7 or Java 8 is wanted, and the proxy will safely invoke either I7 or I8 and the handler will dispatch to MyClass8 ALWAYS even on Java 7. The fact that myClass8 contains JRE 8 code is irrelevant, unless explicitly invoked.

The resulting proxy even is safe to be used with Reflection API as it is a "clean Java 7" object, as the last code line shows.

Isn't the problem that I7 and I8 both have the same name, something like java.sql.ResultSet? There aren't separate interfaces for different JDBC versions, so how do you deal with that?

I think we can stop the discussion at this point. As long as the use of Reflection API upon JDBC objects is a wanted feature, the idea of sharing one single implementation simply won't work, or it will get too complicated to make it work.

When I started this discussion, I only had the JDBC spec in mind as-is, without any use of Reflection API on the JDBC objects, as neither of our own use cases covers this (we de no use such tools).