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

KAFKA-17811: Separate modules to use different JDKs #17522

Merged
merged 17 commits into from
Nov 26, 2024

Conversation

frankvicky
Copy link
Contributor

JIRA: KAFKA-17811

This is sub-task to drop broker and tools support for Java 11.

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@github-actions github-actions bot added build Gradle build or GitHub Actions small Small PRs labels Oct 17, 2024
@frankvicky frankvicky marked this pull request as ready for review October 19, 2024 15:14
Copy link
Contributor

@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@frankvicky thanks for this patch

@@ -128,7 +135,11 @@ ext {
options.compilerArgs << "-Xlint:-serial"
options.compilerArgs << "-Xlint:-try"
options.compilerArgs << "-Werror"
options.compilerArgs += ["--release", String.valueOf(minJavaVersion)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add minClientJavaVersion and minServerJavaVersion?

build.gradle Outdated
@@ -116,6 +116,13 @@ ext {
configureJavaCompiler = { name, options ->
// -parameters generates arguments with parameter names in TestInfo#getDisplayName.
// ref: https://github.com/junit-team/junit5/blob/4c0dddad1b96d4a20e92a2cd583954643ac56ac0/junit-jupiter-params/src/main/java/org/junit/jupiter/params/ParameterizedTest.java#L161-L164

def modulesNeedingJava17 = [
":core", ":coordinator-common", ":generator", ":group-coordinator",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

connect:runtime, connect:mirror, connect:test-plugins, and ``connect:file` should use JDK 17 as well

options.compilerArgs += ["--release", String.valueOf(17)]
} else {
options.compilerArgs += ["--release", String.valueOf(minJavaVersion)]
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please update scala module as well

build.gradle Outdated
":metadata", ":raft", ":server", ":server-common", ":share", ":storage",
":share-coordinator", ":test-common", ":tools", ":transaction-coordinator"
]

if (name == "compileTestJava" || name == "compileTestScala") {
options.compilerArgs << "-parameters"
options.compilerArgs += ["--release", String.valueOf(minJavaVersion)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this need to be updated too.


scalaCompileOptions.additionalParameters += ["-release", String.valueOf(minJavaVersion)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

streams-scala and streams:test-utils need java 11

@@ -47,7 +47,8 @@ plugins {

ext {
gradleVersion = versions.gradle
minJavaVersion = 11
minClientJavaVersion = 11
minServerJavaVersion = 17
buildVersionFileName = "kafka-version.properties"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please move modulesNeedingJava11 up to line#52?

modulesNeedingJava11 = [":clients", ":streams", ":streams:test-utils", ":streams-scala"]

build.gradle Outdated
// -parameters generates arguments with parameter names in TestInfo#getDisplayName.
// ref: https://github.com/junit-team/junit5/blob/4c0dddad1b96d4a20e92a2cd583954643ac56ac0/junit-jupiter-params/src/main/java/org/junit/jupiter/params/ParameterizedTest.java#L161-L164
if (name == "compileTestJava" || name == "compileTestScala") {

def releaseVersion = isModuleNeedJava11(projectPath) ? minClientJavaVersion : minServerJavaVersion
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

def releaseVersion = modulesNeedingJava11.any { projectPath == it } ? minClientJavaVersion : minServerJavaVersion

build.gradle Outdated
@@ -726,7 +734,9 @@ subprojects {
}

tasks.withType(ScalaCompile) {

def modulesNeedingJava11 = [":clients", ":streams", ":streams:test-utils", ":streams-scala"]
def releaseVersion = modulesNeedingJava11.any { project.path.equals(it) } ?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

    def releaseVersion = modulesNeedingJava11.any { project.path == it } ? minClientJavaVersion : minServerJavaVersion

@frankvicky
Copy link
Contributor Author

Hi @chia7712
I have updated the PR, PTAL

build.gradle Outdated
@@ -47,7 +47,10 @@ plugins {

ext {
gradleVersion = versions.gradle
minJavaVersion = 11
minClientJavaVersion = 11
minServerJavaVersion = 17
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be more accurate to say minNonClientJavaVersion as this includes things like tools and other such modules.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sense 😄

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minNonClientJavaVersion looks good to me. Additionally, the connect:api module belongs to client APIs, but in KIP-1032 we decided to bump the Connect module to JDK 17. Could you please add a comment for the Connect module?

Copy link
Contributor

@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@frankvicky could you please check the version of jars on your local?

@frankvicky
Copy link
Contributor Author

Hi @chia7712
Following is the java version of Consumer.class and BrokerFeatures.class
Screenshot from 2024-11-24 21-11-53
Screenshot from 2024-11-24 21-10-07

@chia7712
Copy link
Contributor

@frankvicky Could you please use @SuppressWarnings("removal") to fix the warnings?

> Task :connect:runtime:compileTestJava
/home/chia7712/project/kafka/connect/runtime/src/test/java/org/apache/kafka/connect/runtime/isolation/SynchronizationTest.java:464: warning: [removal] SecurityManager in java.lang has been deprecated and marked for removal
            SecurityManager s = System.getSecurityManager();
            ^
/home/chia7712/project/kafka/connect/runtime/src/test/java/org/apache/kafka/connect/runtime/isolation/SynchronizationTest.java:464: warning: [removal] getSecurityManager() in System has been deprecated and marked for removal
            SecurityManager s = System.getSecurityManager();
                                      ^
2 warnings

@frankvicky
Copy link
Contributor Author

Hi @chia7712
I have suppressed the removal warning, PTAL 😄

@chia7712
Copy link
Contributor

@frankvicky Could you please update CI file to use JDK 17 and 23

https://github.com/apache/kafka/blob/trunk/.github/workflows/build.yml#L148

@chia7712
Copy link
Contributor

https://github.com/apache/kafka/blob/trunk/build.gradle#L1872

@frankvicky please remove the testRuntimeOnly runtimeTestLibs and add

    libs.slf4jReload4j
    libs.junitPlatformLanucher

build.gradle Outdated
@@ -1869,7 +1874,8 @@ project(':clients') {

testRuntimeOnly libs.jacksonDatabind
testRuntimeOnly libs.jacksonJDK8Datatypes
testRuntimeOnly runtimeTestLibs
testRuntimeOnly libs.slf4jReload4j
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please apply this approach on streams module too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have applied to 4 modules which need JDK 11

@chia7712
Copy link
Contributor

@frankvicky I think current approach is incorrect. We should make :test-common:test-common-runtime run under JDK 11 to ensure it can offer common helpers to all modules.

@chia7712 chia7712 merged commit 056a76e into apache:trunk Nov 26, 2024
7 of 8 checks passed
chiacyu pushed a commit to chiacyu/kafka that referenced this pull request Nov 30, 2024
@agavra
Copy link
Contributor

agavra commented Dec 5, 2024

Hey @chia7712 @frankvicky it looks like after merging this PR it's no longer possible (or at least straightforward) to run tests in client modules (specifically streams) from within the IDE (IntelliJ specifically). I'm getting:

> Task :test-common:test-common-runtime:compileJava
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':generator:compileJava'.
> error: release version 17 not supported

I've tried manually setting the module in the project settings but that doesn't seem to work. Would be good to document something in the project README.

Note that it still works using ./gradlew (obviously, or CI wouldn't pass) but since it's pretty custom gradle scripting it seems IntelliJ isn't able to properly pick it up. In the meantime I've just reverted this commit locally, but that's obviously not a long-term proper fix for DevX :)

cc @ableegoldman who was running into similar issues

@chia7712
Copy link
Contributor

chia7712 commented Dec 5, 2024

it's no longer possible (or at least straightforward) to run tests in client modules (specifically streams) from within the IDE (IntelliJ specifically)

Could you please share the details to me? For example, how do you run the tests by IntelliJ?

@agavra
Copy link
Contributor

agavra commented Dec 5, 2024

I'm running it like this:
image

Here's the detailed test configuration:
image

I don't have any special configurations in IDEA, I just use ./gradlew idea to configure it.

@chia7712
Copy link
Contributor

chia7712 commented Dec 5, 2024

@agavra Are you using JDK 11 to run the streams tests? If so, that could be an issue since the generator module requires JDK 17. I assume all Kafka developers should use JDK 17, as we typically build the entire project during development.

@agavra
Copy link
Contributor

agavra commented Dec 5, 2024

🤦 this is why I shouldn't work at night, I had set the module versions to JDK 17 but not the project version to JDK 17. It now works, thanks @chia7712.

@ableegoldman
Copy link
Contributor

I assume all Kafka developers should use JDK 17, as we typically build the entire project during development.

We do indeed need to compile the project with 17, but we should recommend that anyone working on the clients (or any other modules that still support 11) at least set their IDE's language version to JDK11 to avoid accidentally using APIs that don't exist back in 11 (looking at you Optional#isPresent). I also noticed that the PR builds don't show the most clear error when failing due to use of post-JDK-11 APIs :/

@chia7712
Copy link
Contributor

chia7712 commented Dec 8, 2024

@ableegoldman Thanks for your feedback. I agree that we should prioritize making our developers' experience better. I plan to add sourceCompatibility back to build.gradle since IntelliJ IDEA sets the language level based on sourceCompatibility by default (Gradle Documentation).

The screenshot below demonstrates that IntelliJ IDEA can automatically highlight unsupported usages. With this change, developers won't need to manually configure the language level.
Screenshot From 2024-12-09 01-23-49

@chia7712
Copy link
Contributor

chia7712 commented Dec 8, 2024

open KAFKA-18186 to address this.

@ableegoldman please feel free to share your thoughts on this approach.

@ijuma
Copy link
Contributor

ijuma commented Dec 8, 2024

I see some confusion here and I'll try to clarify it.

Are you using JDK 11 to run the streams tests? If so, that could be an issue since the generator module requires JDK 17. I assume all Kafka developers should use JDK 17, as we typically build the entire project during development.

We should make sure it's possible to run tests with Java 11 for the modules that support it since it's possible to have issues at runtime that only affect a particular version.

We do indeed need to compile the project with 17, but we should recommend that anyone working on the clients (or any other modules that still support 11) at least set their IDE's language version to JDK11 to avoid accidentally using APIs that don't exist back in 11 (looking at you Optional#isPresent)

The expected behavior is that the IDE & gradle plugin support the --release flag which has the correct behavior (it sets the appropriate source and binary versions and ensures the standard library signatures also match it).

I plan to add sourceCompatibility back to build.gradle since IntelliJ IDEA sets the language level based on sourceCompatibility by default (Gradle Documentation).

Are we sure the Gradle plugin doesn't handle this properly? If so, we should add the workaround, but also file a ticket with them. See the following for a similar situation for the Scala (the issue here seems to be for Java instead):

#13205 (comment)

@chia7712
Copy link
Contributor

We should make sure it's possible to run tests with Java 11 for the modules that support it since it's possible to have issues at runtime that only affect a particular version.

that makes sense. open https://issues.apache.org/jira/browse/KAFKA-18192 to handle it.

Are we sure the Gradle plugin doesn't handle this properly? If so, we should add the workaround, but also file a ticket with them. See the following for a similar situation for the Scala (the issue here seems to be for Java instead):

The root cause is that we set the compiler arguments directly instead of using Gradle's recommended options.release. I have left a comment on this pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Gradle build or GitHub Actions ci-approved connect small Small PRs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants