Skip to content
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

Merged
merged 7 commits into from Apr 14, 2023

Conversation

jimexist
Copy link
Member

@jimexist jimexist commented Apr 9, 2023

  • upgrade gradle to version 8
  • upgrade toolchain java version to 19
  • upgrade shadow plugin due to incompatible gradle dependency

note this does not change built java library version which is pinned to 11

  • Did you create an Apache Jira ticket? (Request account here, not required for trivial changes)
  • If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
  • Did you squash your changes to a single commit? (not required, but preferred)
  • Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
  • If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

@Jens-G Jens-G added the java Pull requests that update Java code label Apr 9, 2023
@jimexist jimexist requested review from fishy and ctubbsii April 9, 2023 17:07
steps:
- uses: actions/checkout@v3

- uses: actions/setup-java@v3
with:
distribution: temurin
java-version: 17
java-version: 19
Copy link
Member

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?

Copy link
Member Author

@jimexist jimexist Apr 10, 2023

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.

Copy link
Member Author

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

Copy link
Member

@fishy fishy Apr 10, 2023

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?

Copy link
Member Author

@jimexist jimexist Apr 11, 2023

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.

Copy link
Member

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?

Copy link
Member

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

Copy link
Member

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.

steps:
- uses: actions/checkout@v3

- uses: actions/setup-java@v3
with:
distribution: temurin
java-version: 17
java-version: 19
Copy link
Member

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?

@@ -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
Copy link
Member

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

@@ -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
Copy link
Member

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)
Copy link
Member

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?

Copy link
Member

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?

steps:
- uses: actions/checkout@v3

- uses: actions/setup-java@v3
with:
distribution: temurin
java-version: 17
java-version: 19
Copy link
Member

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.

@@ -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
Copy link
Member

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:

Suggested change
# 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)
Copy link
Member

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?

@jimexist jimexist changed the title java lib and build tool chain: gradle 8.0.2 and JDK 19 java lib and build tool chain: gradle 8.0.2 Apr 12, 2023
@jimexist jimexist changed the title java lib and build tool chain: gradle 8.0.2 THRIFT-5699: java lib and build tool chain: gradle 8.0.2 Apr 12, 2023
@jimexist
Copy link
Member Author

@fishy @ctubbsii java version rolled back to 17

@jimexist jimexist merged commit be73a57 into apache:master Apr 14, 2023
9 of 11 checks passed
@Fokko
Copy link
Contributor

Fokko commented Apr 14, 2023

Nice, thanks for picking this up @jimexist

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
java Pull requests that update Java code
Projects
None yet
6 participants