Support a java-11 compile target

[ddanielr]

Users looking to migrate away from ColumnVisibility class usage in accumulo 2.1.x need a version of accumulo-access that supports java-11.

The dependency target was also changed from 3.0.0 to 2.1.4 to ensure users have a supported migration path.

[dlmarion]

I have no issue with these changes, but this reverts some good changes that we made in support of Java 17. I think I would rather see a jdk11 branch created from main and these changes applied there with the inclusion of a jdk11 classifier in the pom. This would allow us to create a 1.0.0 release for jdk11 and jdk17 and declare that the jdk11 version will only get bug fixes for some period of time.

[keith-turner]

These changes are small and very straightforward. The main drawback seems to be the loss of the sealed keyword for improved module support. Do the example commands in the README that use modules still work?

I think I would rather see a jdk11 branch created from main and these changes applied there with the inclusion of a jdk11 classifier in the pom.

A branch sounds good. I would suggest creating a 1.0 branch and putting these changes there. The 1.0 branch would support all 1.0.x bug fixes and be jdk11 for its lifetime. In the main branch we can set the version to 1.1-snapshot and not have the changes in this PR. We can hold off on releasing 1.1 until 1.0 is out of beta and at least a 1.0.0 has been released. When we eventually release 1.1.0 maybe the only change is a newer JDK version.

[ctubbsii]

I think it might be worth doing this as a multi-release jar. We wouldn't need to change the test or example code, just a couple different classes in the core jar. And then we could do a beta3. We could eventually get rid of the Java 11 versions before a final 1.0.0 release.

[keith-turner]

I think it might be worth doing this as a multi-release jar. We wouldn't need to change the test or example code, just a couple different classes in the core jar.

@ctubbsii how would this work end to end? Like at a high level what would need to be done in git, maven, and the release process to make this work?

[ctubbsii]

I think it might be worth doing this as a multi-release jar. We wouldn't need to change the test or example code, just a couple different classes in the core jar.

@ctubbsii how would this work end to end? Like at a high level what would need to be done in git, maven, and the release process to make this work?

You have to put the Java 11 classes in the main build, then have separate copies of the Java 17 classes in a separate build directory in the same branch (like src/main/java17) with a separate maven-compiler-plugin execution using a different --release target. There are some restrictions, like the classes have to have the same API. The tricky part is that it's hard to test as part of the Maven build itself, and some IDEs get confused having two classes with the same name in the project.

See https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html for a starting point, but that's a bit incomplete.

[keith-turner]

You have to put the Java 11 classes in the main build, then have separate copies of the Java 17 classes in a separate build directory in the same branch (like src/main/java17)

That sounds more complex to maintain. If following this route how long do you think this situation would persist in git?

[ctubbsii]

You have to put the Java 11 classes in the main build, then have separate copies of the Java 17 classes in a separate build directory in the same branch (like src/main/java17)

That sounds more complex to maintain. If following this route how long do you think this situation would persist in git?

I guess that depends on the users wanting a Java 11 compatible release. I'm not really a fan of keeping a Java 11 release around at all, because it holds us back from implementing changes that leverage newer Java language features. But, the original post above indicates that there's users who would benefit from that. If it's short term, then it doesn't really matter which method we go with, and it would be easiest to apply this patch, do a beta3 release, and then revert the patch. I only proposed the multi-release as a possibly easier way to maintain the two versions side-by-side indefinitely, in case there are bugs that need to be backported to the Java 11 release.

[keith-turner]

If it's short term, then it doesn't really matter which method we go with, and it would be easiest to apply this patch, do a beta3 release, and then revert the patch

I support taking the path of least resistance for this. If we do that then we always have options in the future to release again for JDK11, we only have to be cognizant of the release numbers. We do not need to leave anything for JDK 11 in git as long we leave a path forward w/ release numbers to do another JDK11 release if needed. We can always create a branch in git at a later time from the JDK11 release and merge an any changes from main. So we could do as little as possible for beta3 release and just remember to consider release numbering on the next release. Like if 1.0.0 is after beta3 would need to make decision about further JDK11 support at that time.

[ctubbsii]

This was released as 1.0.0-beta3, and was reverted by #125 for future versions.