Jochen, I think you misunderstand the problem.
The issue is that there are classes which generate a different signature when compiled with the Java 8 RT vs when compiled with the Java 7 RT. For example, you could have a method that takes a String parameter in Java 7 and was widened to take a CharSequence in Java 8. If your code calls that method with a String, you'd think you'd be ok... Compiling against Java 7 will embed the call to the String parameter method Compiling against Java 8, even with -target 7 will embed a call to the CharSequence parameter method and you will get a method not found when running against Java 7. Now this could be viewed a bug in the Java 8 runtime, as to retain strict support for compiling against 8 and running on 7 you would need to add the wider method, not widen the parameter of the existing method... but Java does not make such a promise... the -target is a convenience only. Now animalsniffer would catch the kind of issue I describe above... but there are more subtle issues, e.g. where there are methods moved to default methods on an interface, etc. These all affect the bytecode. I think what we - as a community - are learning is that we no longer have the luxury of compiling with a newer JDK against an older target... we will have to stick to compiling with the oldest JDK that we support as a runtime... yes we can fall back to -target, animalsniffer and friends, but realistically we need to switch to either aggressively upping the minimum or we need to get better protections in place with regards to central and the java runtime that was used on the compile classpath. We may need to push POM 5.0.0 sooner or risk Central becoming unusable with anything other than the latest JDK (as you have no way of knowing if you'll get bitten with your dependencies compiled using a newer JDK and an old -target and thus embedding the bad usage) Or maybe we can improve animal sniffer to help us detect those issues On 30 November 2014 at 11:33, Jochen Wiedmann <[email protected]> wrote: > 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 <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > Our time is just a point along a line that runs forever with no end. > (Al Stewart, Lord Grenville) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
