I'd solve your problem like this, Mark: - Create an interface for a component, which is internally using the JDK code in question, (say IRTUser). - Create three implementations, each of which are targeting a particular JDK. In what follows, I'll assume that they throw an exception when being instantiated on the wrong JDK. - Ideally, these implementations must be compilable with different JDK'S. (If required, use Java reflection internally to find the right methods, etc. (The above method would be a MethodNotFoundException, or the like.) - Have a factory class, with code like the following:
private static final IRTUser instance = newRTUser(); private static IRTUser newInstance() { try { return new JDK18RTUser(); } catch (Throwable t0) { try { return new JDK17RTUser(); } catch (Throwable t1) { return new JDK16RTUser(); } } public static IRTUser getInstance() { return instance; } This approach has worked fine for me on multiple occasions. Jochen On Thu, Nov 27, 2014 at 9:39 PM, Mark Struberg <strub...@yahoo.de> wrote: > Hi! > > Today I had a discussion with Robert about how we can solve a problem I had > over at Apache OpenWebBeans: > > https://issues.apache.org/jira/browse/OWB-952 > > As a short summary: the classes provided in rt.jar of Java8 are slightly > different than the ones from Java7 and 6. Similar big differences have been > seen in the Java4 to 5 transition. > Thus if you compile your project with Java8 you might get different bytecode > than when compiling with Java7 JDK. Even if you use target=1.7 in both cases. > > There are 2 options: either use javac -bootclasspath and point it to the > 'correct' rt.jar + other jdk libs, or just switch the whole environment. > > Roberts suggestion was to use the Maven Toolchain > system:http://maven.apache.org/plugins/maven-toolchains-plugin/ > http://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk.html > > > We also elaborated about improving the Toolchain lookup in our > maven-compiler-plugin: > http://maven.apache.org/plugins/maven-compiler-plugin/xref/org/apache/maven/plugin/compiler/AbstractCompilerMojo.html#427 > > This could get improved to first check if a toolchain is registered for the > <target> version used in the m-compiler-p. And if there is no toolchain > configured especially for this version then we fallback to the one if we > don't specify a version. > The effective lookup path would then be > 1.) toolchain configured via maven-toolchain-plugin > 2.) toolchain with specified target version > 3.) default toolchain > > > I think we would need to slightly enhance the ToolchainManager, but first > would like to get some feedback. > > > LieGrue, > strub > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Our time is just a point along a line that runs forever with no end. (Al Stewart, Lord Grenville) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org