Coverage remained the same at 93.976% when pulling 2ad3356 on nhojpatrick:CODEC-286 into e87ac43 on apache:master.

I am against the bump to 1.8 for convenience. There should be a good reason for this.

IIUC you can still include collections 3.9 as a test dependency and require Java 8 to run the build, but the target should be 1.7. We should at least get a last release out on the 1.7 target because it contains some fixes that are applicable to those still running against that version of Java.

Having a read of this and you can specify the test source and target separately (see maven compiler plugin):

    <maven.compiler.source>1.7</maven.compiler.source>
    <maven.compiler.target>1.7</maven.compiler.target>
    <maven.compiler.testSource>1.8</maven.compiler.testSource>
    <maven.compiler.testTarget>1.8</maven.compiler.testTarget>

So you can upgrade the build toolchain and tests to JUnit 5 but still support codec at 1.7. When I made the above changes to the pom this worked fine:

@Test
public void useLambda() {
    IntUnaryOperator f = i -> i * i;
    Assert.assertEquals(9, f.applyAsInt(3));
}

The class files extracted from the jar after running mvn package are version 7 (major version: 51) when inspected using javap -v.

Q. Is this going to work for all the other changes you are doing to support a module-info build?

Having a read of this and you can specify the test source and target separately (see maven compiler plugin):

    <maven.compiler.source>1.7</maven.compiler.source>
    <maven.compiler.target>1.7</maven.compiler.target>
    <maven.compiler.testSource>1.8</maven.compiler.testSource>
    <maven.compiler.testTarget>1.8</maven.compiler.testTarget>

So you can upgrade the build toolchain and tests to JUnit 5 but still support codec at 1.7. When I made the above changes to the pom this worked fine:

@Test
public void useLambda() {
    IntUnaryOperator f = i -> i * i;
    Assert.assertEquals(9, f.applyAsInt(3));
}

The class files extracted from the jar after running mvn package are version 7 (major version: 51) when inspected using javap -v.

Q. Is this going to work for all the other changes you are doing to support a module-info build?

changed as suggested

I am against the bump to 1.8 for convenience. There should be a good reason for this.

IIUC you can still include collections 3.9 as a test dependency and require Java 8 to run the build, but the target should be 1.7. We should at least get a last release out on the 1.7 target because it contains some fixes that are applicable to those still running against that version of Java.

should I bump a major version bump then and that be 1.8 and 11 dual support. e.g. 1.8 src/main/java and src/test/java, with 11 for just src/main/java11/module-info.java?

if someone could created a v2.x branch from master i'll be happy to get that working and also keep back porting v1.x fixes into the branch.

My question was whether your dual support would work with 1.7 and 11? Is there any difference with regard to modules between 1.7 and 1.8 since they are both pre java 9.

You can update the build tools to 1.8 so the changes are consistent across the four projects you are addressing (and you know it works), but the final jar has 1.7 class files.

My question was whether your dual support would work with 1.7 and 11? Is there any difference with regard to modules between 1.7 and 1.8 since they are both pre java 9.

You can update the build tools to 1.8 so the changes are consistent across the four projects you are addressing (and you know it works), but the final jar has 1.7 class files.

1.7 and 11 dual support should work... but never tried it, will try it out

but some other conversations around spring and class scanners might break so the dual support i'm thinking should be a major version bump. so then anyone upgrading knows it's a major change and as such can correctly tests before releasing themselves.

See how far you get. I'm happy to roll a final release at 1.7 if the consensus is to bump to 1.8 moving forward. There is an unreleased regression fix to restore some functionality from prior to v1.13 that is blocking some upgraders. Getting this out would allow users to upgrade and get all the other 1.13-1.15 work (about 1 year of change history) while not having to switch java versions.

In order to KISS it, perhaps we can: - Release on more time on Java 7 - Update to Java 8 Gary
…
On Tue, Mar 3, 2020 at 7:11 AM Alex Herbert @.***> wrote: Having a read of this and you can specify the test source and target separately (see maven compiler plugin https://maven.apache.org/plugins/maven-compiler-plugin/testCompile-mojo.html ): <maven.compiler.source>1.7</maven.compiler.source> <maven.compiler.target>1.7</maven.compiler.target> <maven.compiler.testSource>1.8</maven.compiler.testSource> <maven.compiler.testTarget>1.8</maven.compiler.testTarget> So you can upgrade the build toolchain and tests to JUnit 5 but still support codec at 1.7. When I made the above changes to the pom this worked fine: @test public void useLambda() { IntUnaryOperator f = i -> i * i; Assert.assertEquals(9, f.applyAsInt(3)); } The class files extracted from the jar after running mvn package are version 7 (major version: 51) when inspected using javap -v. Q. Is this going to work for all the other changes you are doing to support a module-info build? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#40?email_source=notifications&email_token=AAJB6N4SM7JJ3IPB5UAPXELRFTXVZA5CNFSM4K72BQRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENTH3PI#issuecomment-593919421>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJB6N4GIDOHMMTDZRTHKITRFTXVZANCNFSM4K72BQRA .

makes a lot of sense, i'm after 1.8 and 11 dual, and i understand and appreciated for some they need a stepping stone towards it. Until recently I was working on 1.6, 1.7 and 1.8 at work, over past 18 months we have managed to get all now on 1.8 with most frameworks or shared code doing dual support for 1.8 and 11.

So major version for each? so if needed we can do bug fixes for 1.7, 1.8 and 1.8/11 if needed.