-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
THRIFT-5699: java lib and build tool chain: gradle 8.0.2 #2779
Conversation
.github/workflows/build.yml
Outdated
steps: | ||
- uses: actions/checkout@v3 | ||
|
||
- uses: actions/setup-java@v3 | ||
with: | ||
distribution: temurin | ||
java-version: 17 | ||
java-version: 19 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
19 is not an LTS version, we should stick with LTS versions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for maintainability i think we should stick with 11 for released jars (which is guaranteed using -release
flag). i trust JDK's capability of down-compiling with newer Java versions.
for build tool chain (CI) i think it is okay to move along with newest stable release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the -release
flag was introduced by @ctubbsii
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my main concern is that someone accidentally introduced some code that requires feature not available in LTS versions, but if that's already guaranteed by -release
flag then I think this is fine.
the other concern is that the non-LTS versions all have a relatively much shorter support lifespan so we need to update those to supported versions much more frequently. For example, according to https://www.oracle.com/java/technologies/java-se-support-roadmap.html 19 is already out of support?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can move to java 21 in September but atm i think it is fine given there's no much of a support needed, given the compiled .class
files are in Java 11. The only support needed is in the build system in this repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
out of support would also mean that it won't get security fixes, so if a security bug is discovered in jdk 19 now the fix would only land on 20 and LTS versions, not 19, I assume? But maybe Oracle's "sustaining support" means it would still get security fixes?
if we are not using any new features introduced since 17 (the latest LTS version right now), I'm not sure why do we need to use java 19 here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is to check if we are prepared to run build/tests with upcoming releases.
I would recommend to use 20 here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any reason to test with the newer JDK that's available. But, I would suggest prioritizing testing against a JDK that developers are more likely to be using... like the current LTS. If we want to build against both, it's pretty easy to set up a Matrix build in GitHub Actions.
.github/workflows/build.yml
Outdated
steps: | ||
- uses: actions/checkout@v3 | ||
|
||
- uses: actions/setup-java@v3 | ||
with: | ||
distribution: temurin | ||
java-version: 17 | ||
java-version: 19 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
out of support would also mean that it won't get security fixes, so if a security bug is discovered in jdk 19 now the fix would only land on 20 and LTS versions, not 19, I assume? But maybe Oracle's "sustaining support" means it would still get security fixes?
if we are not using any new features introduced since 17 (the latest LTS version right now), I'm not sure why do we need to use java 19 here?
doc/install/README.md
Outdated
@@ -28,8 +28,8 @@ These are only required if you choose to build the libraries for the given langu | |||
* zlib (optional) | |||
* Qt (optional) | |||
* Java | |||
* Java 17 | |||
* Gradle 7.6 | |||
* Java 19 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please leave 11/17 here
lib/java/gradle/unitTests.gradle
Outdated
@@ -65,7 +65,7 @@ test { | |||
outputs.upToDateWhen { false } | |||
} | |||
|
|||
// This is required for Mockito to run under Java 17 | |||
// This is required for Mockito to run under Java 19 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
leave as "17+"
@@ -31,7 +31,7 @@ | |||
// also a runtime CI that's based on Java 11 to ensure that. | |||
java { | |||
toolchain { | |||
languageVersion = JavaLanguageVersion.of(17) | |||
languageVersion = JavaLanguageVersion.of(19) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so with this definition - java defined with github actions setup is onoy used for Gradle process and not to build/run tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this forces developers to build using JDK 19. I would prefer not to do that. I think many developers are perfectly content to build using the latest LTS, which I think is still 17. The build should still work with later versions, but I don't think the build should require anything later than 17. I'm not very experienced with Gradle, but I think that's what this does.
Can we bump to the newest Gradle without forcing devs to develop using newer than JDK 17?
.github/workflows/build.yml
Outdated
steps: | ||
- uses: actions/checkout@v3 | ||
|
||
- uses: actions/setup-java@v3 | ||
with: | ||
distribution: temurin | ||
java-version: 17 | ||
java-version: 19 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any reason to test with the newer JDK that's available. But, I would suggest prioritizing testing against a JDK that developers are more likely to be using... like the current LTS. If we want to build against both, it's pretty easy to set up a Matrix build in GitHub Actions.
.github/workflows/build.yml
Outdated
@@ -431,7 +431,7 @@ jobs: | |||
- uses: actions/setup-java@v3 | |||
with: | |||
distribution: temurin | |||
# here we intentionally use an older version so that we also verify java 17 compiles to it | |||
# here we intentionally use an older version so that we also verify java 19 compiles to it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could omit the version here, so it doesn't need to be updated so often. Just say:
# here we intentionally use an older version so that we also verify java 19 compiles to it | |
# intentionally use Java 11 here to ensure that the newer JDK builds for Java 11 |
@@ -31,7 +31,7 @@ | |||
// also a runtime CI that's based on Java 11 to ensure that. | |||
java { | |||
toolchain { | |||
languageVersion = JavaLanguageVersion.of(17) | |||
languageVersion = JavaLanguageVersion.of(19) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this forces developers to build using JDK 19. I would prefer not to do that. I think many developers are perfectly content to build using the latest LTS, which I think is still 17. The build should still work with later versions, but I don't think the build should require anything later than 17. I'm not very experienced with Gradle, but I think that's what this does.
Can we bump to the newest Gradle without forcing devs to develop using newer than JDK 17?
Nice, thanks for picking this up @jimexist |
upgrade toolchain java version to 19note this does not change built java library version which is pinned to 11
[skip ci]
anywhere in the commit message to free up build resources.