=================
This Memory component is general purpose, has no external runtime dependencies and can be used in any application that needs to manage data structures inside or outside the Java heap.
Please visit the main DataSketches website for more information.
If you are interested in making contributions to this Memory component please see our Community page.
The goal of this component of the DataSketches library is to provide a high performance access API for accessing six different types of memory resources. Each of the six resource types is accessed using different API methods.
Note: primitive = {byte, short, int, long, float, double}
Heap:
Heap via ByteBuffer
Direct:
Direct via ByteBuffer
Memory-Mapped Files
These are transitional releases that also supports Java 8 and 11. However, the goal of this set of releases is to migrate the API to what it will be in release 4.0.0. The 4.0.0 release will require Java 17 and will utilize the Project Panama (FFM) capabilites introduced in Java 17.
Some of the capabilites of releases [2.0.0, 3.0.0) have been removed because they cannot be supported in release 4.0.0 with Panama-17. For example:
Release 3.0.0 includes two bug fixes (Issues #194, #195).
It is our expectation that this set of releases will be the last that support Java 8 and 11.
The comments in the following section for releases [2.0.0, 3.0.0) still apply.
Starting with release datasketches-memory-2.0.0, this Memory component supports Java 8 and 11. Providing access to the off-heap resources in Java 8 only requires reflection. However, Java 9 introduced the Java Platform Module System (JPMS) where access to these internal classes requires starting up the JVM with special JPMS arguments. The actual JVM arguments required will depend on how the user intends to use the Memory API, the Java version used to run the user's application and whether the user's application is a JPMS application or not.
Also see the usage examples for more information.
In this environment, the user is using the Jars from Maven Central as a library dependency and not attempting to build the Memory component from the source code or run the Memory component tests.
Otherwise, if you are running Java 11-13 and ...
JVM Arguments for non-JPMS Applications | Direct ByteBuffer | Direct | MemoryMapped Files |
---|---|---|---|
--add-exports java.base/jdk.internal.misc= ALL-UNNAMED | Yes | ||
--add-exports java.base/jdk.internal.ref= ALL-UNNAMED | Yes | Yes | |
--add-opens java.base/java.nio= ALL-UNNAMED | Yes | Yes | |
--add-opens java.base/sun.nio.ch= ALL-UNNAMED | Yes |
JVM Arguments for JPMS Applications | Direct ByteBuffer | Direct | MemoryMapped Files |
---|---|---|---|
--add-exports java.base/jdk.internal.misc= org.apache.datasketches.memory | Yes | ||
--add-exports java.base/jdk.internal.ref= org.apache.datasketches.memory | Yes | Yes | |
--add-opens java.base/java.nio= org.apache.datasketches.memory | Yes | Yes | |
--add-opens java.base/sun.nio.ch= org.apache.datasketches.memory | Yes | Yes |
In this environment the developer needs to build the Memory component from source and run the Memory Component tests. There are two use cases. The first is for a System Developer that needs to build and test their own Jar from source for a specific Java version. The second use case is for a Memory Component Developer and Contributor.
System Developer
Memory Component Developer / Contributor
NOTES:
1) This component accesses resource files for testing. As a result, the directory elements of the full absolute path of the target installation directory must qualify as Java identifiers. In other words, the directory elements must not have any space characters (or non-Java identifier characters) in any of the path elements. This is required by the Oracle Java Specification in order to ensure location-independent access to resources: See Oracle Location-Independent Access to Resources
There are no run-time dependencies. See the pom.xml file for test dependencies.
The Maven build requires the following JDKs to compile:
Before building, first ensure that your local environment has been configured according to the Maven Toolchains Configuration.
There are two types of tests: normal unit tests and continuous integration(CI) tests. The CI tests target the Multi-Release (MR) JAR and run the entire test suite using a specific version of Java. Running the CI test command also runs the default unit tests.
To run normal unit tests:
mvn clean test
To run javadoc on this multi-module project, use:
mvn clean javadoc:javadoc -DskipTests=true
To build the multi-release JAR, use:
mvn clean package
To run the eclipse plugin on this multi-module project, use:
mvn clean eclipse:eclipse -DskipTests=true
To install jars built from the downloaded source:
mvn clean install -DskipTests=true
This will create the following Jars:
A build script named package-single-release-jar.sh has been provided to package a JAR for a specific java version. This is necessary in cases where a developer is unable to install all the required versions of the JDK that are required as part of the Maven build.
The build script performs the following steps:
The build script is located in the tools/scripts/ directory and requires the following arguments:
For example, if the project base directory is /src/datasketches-memory
;
To run the script for a release version:
./tools/scripts/package-single-release-jar.sh $JAVA_HOME 2.1.0 /src/datasketches-memory
To run the script for a snapshot version:
./tools/scripts/package-single-release-jar.sh $JAVA_HOME 2.2.0-SNAPSHOT /src/datasketches-memory
To run the script for an RC version:
./tools/scripts/package-single-release-jar.sh $JAVA_HOME 2.1.0-RC1 /src/datasketches-memory
Note that the script does not use the Git Version Tag to adjust the working copy to a remote tag - it is expected that the user has a pristine copy of the desired branch/tag available before using the script.
For more information on the project configuration, the following topics are discussed in more detail:
In order to build and contribute to this project, please read the relevant IDE documentation:
For releasing to AppNexus, please use the sign-deploy-jar.sh
script in the scripts directory.
See the documentation within the script for usage instructions.