Specify Multi-Release property in manifest #12131
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tag: bugfix
This is a very simple PR that modifies Pinot to include the standard tag
Multi-Release
in the shaded manifest.This tag is defined in JEP-238. When specified, Java runtime 9 and newer consider the jar as a multi-release jar. You can read the JEP to have more context, but the TL;DR is that multi release jars may include more than one .class file for each Java class. Each .class can be optionally be associated with a given Java version and the JVM will load the correct class depending on their version.
For example, for a given class X, the jar may include a standard X and a custom version of X to be used in Java 11. In this case when running with Java 8, 9 or 10, the standard X will be used but the runtime is Java 11 or higher, it will use the Java 11 version.
It is important to note that we do not provide custom classes for any runtime, but our dependencies do include them. Given that by default we distribute Pinot in a fat-jar, we need to enable Multi-Release in our uber-jar to inform Java that it should use the newest classes.
For example, Lucene or Roaring Bitmap provide their own classes and even we include them in our uber-jar, Java does not load them right now because the Manifest doesn't say so. In the case of Lucene that is a problem because the standard org.apache.lucene.store.MemorySegmentIndexInput class doesn't work in Java 21.
In order to try this PR I've just did the following:
mvn clean
mvn install package -DskipTests -Pbin-dist -Pbuild-shaded-jar -Djdk.version=11 -T1C
(which is what Dockerbuild does)build/lib/pinot-all-1.1.0-SNAPSHOT-jar-with-dependencies.jar
META-INF/MANIFES.MF
contains Multi-Release: trueMETA-INF/versions/...
is not empty (this is not necessary given these classes were already there, but just to verify that).