> 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. +1 > 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... +1 I don't fully agree with the other summary though. I think we have a better option but we need to work it out a bit. The ToolchainManager really looks like a nice way we could probably do that. Usually a project would not care much which JDK version is installed, but by using the toolchains.xml we have a way to declare the exact environment one likes to use. That way one can define that a certain Java7 and Java8 JDK should be used. Currently this needs an explicit configuration of the maven-toolchain-plugin, and there is also no way to 'enforce' a specific setup to be done. E.g. that someone needs to have the toolchains.xml and the 1.6 and 1.8 JDKs needs to be in there. There are 2 things I like to improve: 1.) enhance enforcer rules to include toolchains.xml or make maven itself handle it 2.) enhance the ToolchainManager to let lookup configured Toolchains and use this in maven-compiler-plugin and maven-test-plugin to use a 'preferred' Toolchain version. E.g. if target=1.7 is defined it should try to resolve this Toolchain. I also like to give you a sample usage what I like to be able. In Apache OpenJPA we currently have an issue with Entities using Java8 Lambdas and Streaming API. The enhancement is broken for them. But I'm currently not able to define an additional module which uses Java8 and contains those Java8 feature tests. If I would add such a Java8 test module then I would today need to build the whole application with Java8. But then the aforementioned bytecode issues would appear. Most of this is already possible today with Toolchains. Just explicitly use the maven-toolchains-plugin in your pom and make sure the toolchains.xml is setup correctly. Of course both of it should just be one or two lines in the poms in the future. And I would love to have a switch in my project to make the toolchains.xml and some well specified Toolchains mandatory for it. And ideally with a link to our page describing how to setup toolchains.xml... LieGrue, strub On Sunday, 30 November 2014, 12:58, Stephen Connolly <[email protected]> wrote: > >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] >> >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
