You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Chia-Ping Tsai (Jira)" <ji...@apache.org> on 2025/02/04 02:36:00 UTC
[jira] [Commented] (KAFKA-18459) Support multiple JDKs in ducktape
[ https://issues.apache.org/jira/browse/KAFKA-18459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923545#comment-17923545 ]
Chia-Ping Tsai commented on KAFKA-18459:
----------------------------------------
[~cmccabe] thanks for your feedback. While supporting multiple JDKs would be the ideal approach as you suggested, I initially avoided it due to the complexity involved. However, I agree that the current approach of replacing zk jars is a hack. I will take over this Jira and investigate a more suitable way to deliver this change to trunk/4.0.
> Support multiple JDKs in ducktape
> ---------------------------------
>
> Key: KAFKA-18459
> URL: https://issues.apache.org/jira/browse/KAFKA-18459
> Project: Kafka
> Issue Type: Sub-task
> Affects Versions: 4.0.0
> Reporter: Colin McCabe
> Priority: Major
>
> Eventually we will need to support multiple JDKs in ducktape.
> One example of why we might want to do this is that we currently hack the older releases to use a different ZK library than what they shipped with. We do this because ZK 3.4 and earlier are not compatible with JDK 17 and newer. But this is not the library the older Kafka release was actually released with, so this setup may introduce subtle bugs (or maybe not, if we didn't use anything that was removed in the newer ZK versions?)
> Eventually Oracle will probably make some breaking change in the JDK that will require us to use historic JDKs for historic Kafka releases. For now, we're hacking it to all use one new JDK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)