Update to Java 11 & support JPMS #1474
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
balamurugana
requested changes
Jul 21, 2023
| sourceCompatibility = JavaVersion.VERSION_1_8 | ||
| targetCompatibility = JavaVersion.VERSION_1_8 | ||
| sourceCompatibility = JavaVersion.VERSION_11 | ||
| targetCompatibility = JavaVersion.VERSION_11 |
There was a problem hiding this comment.
Our source code and minimum supported version is 1.8.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Motivation
JPMS is used by the vast majority of publically released libraries. The performance benefits it provides over the generic classpath, and better compile-time verification is very important. Without native support for JPMS, nobody can release a public library using JPMS and Minio safely.
Downsides
This will break support for Java 1.8, and Java 9 or over will be needed to use Minio. In the PR that I have created, Java 11 is the base version as it is the next LTS release after 1.8. Most people consider Java 1.8 as "ancient" by modern standards, but it is still used today in a lot of commercial software. The best way to maintain support will be to simply refer people to the older versions of the client, or the official S3 clients.
A hacky way people tend to retain support for Java 1.8 is to compile the module-info with Java 9/11, and the rest of the project with Java 1,8. This is not the most elegant build toolchain but is a valid solution nevertheless.
Issues
This PR should not build correctly, as I have not thoroughly checked if all
requiresstatements are defined, and there are likely several other issues.This PR also uses
open modulefor all of the declarations, as I was conducting some quick tests with Spring - this can be changed, and probably should be changed as the client does not seem to require any kind of reflection.