> Can we bump the requirement to build OpenJPA to Java 8 as > long as we continue to build the runtime at a java 7 class level?
That is one of the goals of maven toolchains. I'd combine the maven-toolchains-plugin with the animalsniffer plugin. There are 2 problematic points when compiling java7 code with idk-1.8: 1.) Unknowingly introducing Java8 methods or classes in the source. This is pretty easy to track/detect via the animalsniffer-maven-plugin [1]. 2.) Have javac coerc valid java7 code to methods/classes/interfaces which only got introduced in Java8. This is really a nightmare as you can hardly find it. The source is perfectly fine but when compiled with a rt.jar from java8 it will create bytecode which doesn't run on a java7 installation. Both of those issues can be solved with maven toolchains. But all the people who like to compile openjpa need to have both java7 and 8 installed and they also need a properly set up ~/.m2/toolchains.xml file (see the sample I committed to Apache Tamaya). Over in Tamaya we compile all with java8 (maven requirement) and only activate the maven-toolchains-plugin to force java7 in some modules via a maven profile (-Pjava7). This profile also gets activated during release. That way all users can build oipenjpa (with java8) but the binaries we create during release are perfectly valid in Java7 as well. LieGrue, strub [1] http://mojo.codehaus.org/animal-sniffer-maven-plugin/ On Monday, 19 January 2015, 15:42, Rick Curtis <curti...@gmail.com> wrote: >Mark -- > > >> The idea is to have a java8 module which has entities with java8 features so >> we can better test those. The reason I like to have this is that I did not >> manage to get OpenJPA working with entities containing lambdas. > > >I don't have time this morning to dig into toolchains, but it seems like a >reasonable approach. I have one (possibly bad) thought that I wanted to run by >others. Can we bump the requirement to build OpenJPA to Java 8 as long as we >continue to build the runtime at a java 7 class level? I'm not sure if this >runs the risk of referencing java8 class libraries that will compile, but >won't work at runtime due to class format version errors? ... or perhaps there >are other reasons why this is a bad idea? > > >> The reason I like to have this is that I did not manage to get OpenJPA >> working with entities containing lambdas. >Can you send some more details (perhaps on a separate thread) about these >problems? Joe did a bunch of work late last year to get Entities to work with >java8 language features. He(?) has a bunch of tests that could probably be >contributed once our build is able to support doing so. I believe these >changes made it into trunk and 2.2.x. > > >> shouldn't we rework enhancement before - hoping to simplify the build >> before? > >I know we've been saying that we need to ditch serp for ASM for quite a long >time... but that is a rather terrifying change. If someone is going to try to >tackle this task, I'd prefer to see the work done in a separate experimental >branch. I don't foresee that change going smoothly. > > >Thanks, >Rick > > > > >On Sun, Jan 18, 2015 at 11:06 AM, Mark Struberg <strub...@yahoo.de> wrote: > >Hi! >> >>I have a suggestion about how we can imporove our support for Java8. >> >>Maven is able to use different 'toolchains' [1] and make any module choose >>which one to use [2]. >> >>You can see how I did set this up in Apache Tamaya [3] >> >>The idea is to have a java8 module which has entities with java8 features so >>we can better test those. >>The reason I like to have this is that I did not manage to get OpenJPA >>working with entities containing lambdas. >> >>LieGrue, >>strub >> >>[1] http://maven.apache.org/guides/mini/guide-using-toolchains.html >>[2] http://maven.apache.org/plugins/maven-toolchains-plugin/ >>[3] >>https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=blob;f=java7/pom.xml;h=d4a8c7b9c0b93919a38a5690f32ed2729704ea93;hb=HEAD#l89 >> > > > >-- > >Rick Curtis > > >
