Support newer java versions #131
Conversation
The purpose of this change is to create a release that is usable from multilpe Java versions. This initially supports parity with the current release, which is now baselined to Java8.
Separate the java8 source and tests into separate maven modules.
This module depends on all other modules in the project, and is used to assemble JARs for installation to a local repository or deployment to a remote repository.
Extend the assembled JAR to allow multiple, Java-release-specific versions of class files to coexist in a single archive. See JEP-238.
Extract the platform specific features to the java9 maven module: - reference cleaner - nio bits fields - virtual machine memory fields This makes use of the new MR-jar to coexist with the java8 equivalents.
Fixes compiler error where internals are not accessible to java9 related code. Furthermore, a JPMS module is defined for the datasketches-memory, that can be used to narrow any additional compiler or runtime arguments for the JPMS.
This module runs the test suite against the packaged JAR, using the java version defined by the environment that runs maven.
This prevents unsupported runtime flags being used in Java8 during test execution using the Maven surefire plugin.
This allows us to verify that the MR-Jar works across various JVMs by running the unit test suite across each Java version.
| ### JDK8/Hotspot is required to compile | ||
| This DataSketches component is pure Java and you must compile using JDK 8 with Hotspot. | ||
| ### JDK versions required to compile | ||
| This DataSketches component is pure Java and requires the following JDKs to compile: |
There was a problem hiding this comment.
I think you mean "one of the following". (certainly not all of them simultaneously :) )
There was a problem hiding this comment.
I am not sure how to clarify this documentation - as the Maven toolchain build requires these three java versions to be present on the developer's machine in order to build the project successfully. The end-user does not require all java versions to be present simultaneously.
Do you think that this needs further explanation in the README?
|
This is a great PR. I really appreciate the work you put into the documentation!! So many of the files were just a path name change that the review process went a lot faster than I expected. I still have potentially 1 or 2 files I want to move in from datasketches-java, but we could do that after this merge. If you can fix the LGTM problem that would be great, but if it is too much of a hassle, I wouldn't worry about it. |
Thanks for the positive feedback!
This is currently logged with asf-infra, but if it takes too long to resolve we can discuss alternatives. |
This prevents the memory assembly artifacts depending on the root module. However, this configuration duplicates some properties between the root and assembly POM files.
This is a major rework of the memory project structure that provides support for Java 8, as well as Java 9 through 13.
The changes leverage improvements in the Java ecosystem such as the Java Module System (JPMS), and multi-release JARs (MR-Jars).
The PR here is a consolidation of work conducted together with @leerho over several months, and documentation has been provided to the rationale for the changes.
For further information, see this issue: #121