You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@kudu.apache.org by Zoltan Chovan <zc...@cloudera.com> on 2025/08/06 12:09:51 UTC
Proposal to move to JDK17
Hi,
I'm proposing deprecating Java 8 support and establishing Java 17 as the
minimum required version for Apache Kudu Java components.
Apache Kudu currently supports Java 8+ for both runtime and build
environments, as documented in our installation and developer guides.
However, Java 8 reached End of Public Updates in January 2019 and Extended
Support will end in December 2030. Meanwhile, Java 17 is the current Long
Term Support (LTS) release and offers significant improvements in
performance, security, and developer experience.
I opened KUDU-3681 <https://issues.apache.org/jira/browse/KUDU-3681> to
track this effort, and I already have a patch
<https://gerrit.cloudera.org/c/23259/> up for review on gerrit.
One of the major changes come from upgrading our Hive dependency, since
Hive 4.1.0 no longer supports building with Java 8, in turn the Kudu Java
client wouldn't be buildable with this upgraded dependency either.
I already asked for feedback back in September, however I never received
any feedback, so I'm attempting to gather some comments again.
If you are a user of the Kudu Java client and this change would affect
you/your product/your workflow and have any comments or concerns please let
me know!
Best regards,
Zoltan
Re: Proposal to move to JDK17
Posted by Zoltan Chovan <zc...@cloudera.com.INVALID>.
Hi Abhishek,
Thanks for the feedback! I don't think keeping Java8 backwards
compatibility is a good idea.
* This would basically double the testing that we need to do with any
releases going forward.
* Since the Java bits are mainly the client and the BDR job, the older
(i.e. Java8) releases will be compatible with newer Kudu versions, as long
as we don't have backwards incompatible API changes.
* Introduces further complexities into dist-test/precommit testing.
By no means are these deal breakers, but I just don't really see a benefit
for the amount of extra work this would add.
Best regards,
Zoltan
On Thu, Aug 7, 2025 at 1:16 AM Abhishek Chennaka <ac...@apache.org>
wrote:
> Hi Zoltan,
>
> This proposal to move to JDK 17 sounds like a good next step for the Kudu
> Java components. The benefits in terms of performance, security, and
> developer experience from upgrading to a newer LTS release are beneficial
> for users.
>
> However, as we proceed with this upgrade, I believe it's crucial to ensure
> that backwards compatibility is preserved as much as possible for existing
> users of the Kudu Java client. This will help minimize any potential
> disruption to their products or workflows.
>
> Thanks for taking the initiative on this.
>
> Thanks,
> Abhishek
>
> On Wed, Aug 6, 2025 at 5:10 AM Zoltan Chovan <zc...@cloudera.com.invalid>
> wrote:
>
>> Hi,
>>
>> I'm proposing deprecating Java 8 support and establishing Java 17 as the
>> minimum required version for Apache Kudu Java components.
>>
>> Apache Kudu currently supports Java 8+ for both runtime and build
>> environments, as documented in our installation and developer guides.
>> However, Java 8 reached End of Public Updates in January 2019 and Extended
>> Support will end in December 2030. Meanwhile, Java 17 is the current Long
>> Term Support (LTS) release and offers significant improvements in
>> performance, security, and developer experience.
>>
>> I opened KUDU-3681 <https://issues.apache.org/jira/browse/KUDU-3681> to
>> track this effort, and I already have a patch
>> <https://gerrit.cloudera.org/c/23259/> up for review on gerrit.
>>
>> One of the major changes come from upgrading our Hive dependency, since
>> Hive 4.1.0 no longer supports building with Java 8, in turn the Kudu Java
>> client wouldn't be buildable with this upgraded dependency either.
>>
>> I already asked for feedback back in September, however I never received
>> any feedback, so I'm attempting to gather some comments again.
>>
>> If you are a user of the Kudu Java client and this change would affect
>> you/your product/your workflow and have any comments or concerns please
>> let
>> me know!
>>
>> Best regards,
>> Zoltan
>>
>
Re: Proposal to move to JDK17
Posted by Zoltan Chovan <zc...@cloudera.com>.
Hi Abhishek,
Thanks for the feedback! I don't think keeping Java8 backwards
compatibility is a good idea.
* This would basically double the testing that we need to do with any
releases going forward.
* Since the Java bits are mainly the client and the BDR job, the older
(i.e. Java8) releases will be compatible with newer Kudu versions, as long
as we don't have backwards incompatible API changes.
* Introduces further complexities into dist-test/precommit testing.
By no means are these deal breakers, but I just don't really see a benefit
for the amount of extra work this would add.
Best regards,
Zoltan
On Thu, Aug 7, 2025 at 1:16 AM Abhishek Chennaka <ac...@apache.org>
wrote:
> Hi Zoltan,
>
> This proposal to move to JDK 17 sounds like a good next step for the Kudu
> Java components. The benefits in terms of performance, security, and
> developer experience from upgrading to a newer LTS release are beneficial
> for users.
>
> However, as we proceed with this upgrade, I believe it's crucial to ensure
> that backwards compatibility is preserved as much as possible for existing
> users of the Kudu Java client. This will help minimize any potential
> disruption to their products or workflows.
>
> Thanks for taking the initiative on this.
>
> Thanks,
> Abhishek
>
> On Wed, Aug 6, 2025 at 5:10 AM Zoltan Chovan <zc...@cloudera.com.invalid>
> wrote:
>
>> Hi,
>>
>> I'm proposing deprecating Java 8 support and establishing Java 17 as the
>> minimum required version for Apache Kudu Java components.
>>
>> Apache Kudu currently supports Java 8+ for both runtime and build
>> environments, as documented in our installation and developer guides.
>> However, Java 8 reached End of Public Updates in January 2019 and Extended
>> Support will end in December 2030. Meanwhile, Java 17 is the current Long
>> Term Support (LTS) release and offers significant improvements in
>> performance, security, and developer experience.
>>
>> I opened KUDU-3681 <https://issues.apache.org/jira/browse/KUDU-3681> to
>> track this effort, and I already have a patch
>> <https://gerrit.cloudera.org/c/23259/> up for review on gerrit.
>>
>> One of the major changes come from upgrading our Hive dependency, since
>> Hive 4.1.0 no longer supports building with Java 8, in turn the Kudu Java
>> client wouldn't be buildable with this upgraded dependency either.
>>
>> I already asked for feedback back in September, however I never received
>> any feedback, so I'm attempting to gather some comments again.
>>
>> If you are a user of the Kudu Java client and this change would affect
>> you/your product/your workflow and have any comments or concerns please
>> let
>> me know!
>>
>> Best regards,
>> Zoltan
>>
>
Re: Proposal to move to JDK17
Posted by Abhishek Chennaka <ac...@apache.org>.
Hi Zoltan,
This proposal to move to JDK 17 sounds like a good next step for the Kudu
Java components. The benefits in terms of performance, security, and
developer experience from upgrading to a newer LTS release are beneficial
for users.
However, as we proceed with this upgrade, I believe it's crucial to ensure
that backwards compatibility is preserved as much as possible for existing
users of the Kudu Java client. This will help minimize any potential
disruption to their products or workflows.
Thanks for taking the initiative on this.
Thanks,
Abhishek
On Wed, Aug 6, 2025 at 5:10 AM Zoltan Chovan <zc...@cloudera.com.invalid>
wrote:
> Hi,
>
> I'm proposing deprecating Java 8 support and establishing Java 17 as the
> minimum required version for Apache Kudu Java components.
>
> Apache Kudu currently supports Java 8+ for both runtime and build
> environments, as documented in our installation and developer guides.
> However, Java 8 reached End of Public Updates in January 2019 and Extended
> Support will end in December 2030. Meanwhile, Java 17 is the current Long
> Term Support (LTS) release and offers significant improvements in
> performance, security, and developer experience.
>
> I opened KUDU-3681 <https://issues.apache.org/jira/browse/KUDU-3681> to
> track this effort, and I already have a patch
> <https://gerrit.cloudera.org/c/23259/> up for review on gerrit.
>
> One of the major changes come from upgrading our Hive dependency, since
> Hive 4.1.0 no longer supports building with Java 8, in turn the Kudu Java
> client wouldn't be buildable with this upgraded dependency either.
>
> I already asked for feedback back in September, however I never received
> any feedback, so I'm attempting to gather some comments again.
>
> If you are a user of the Kudu Java client and this change would affect
> you/your product/your workflow and have any comments or concerns please let
> me know!
>
> Best regards,
> Zoltan
>
Re: Proposal to move to JDK17
Posted by Abhishek Chennaka <ac...@apache.org>.
Hi Zoltan,
This proposal to move to JDK 17 sounds like a good next step for the Kudu
Java components. The benefits in terms of performance, security, and
developer experience from upgrading to a newer LTS release are beneficial
for users.
However, as we proceed with this upgrade, I believe it's crucial to ensure
that backwards compatibility is preserved as much as possible for existing
users of the Kudu Java client. This will help minimize any potential
disruption to their products or workflows.
Thanks for taking the initiative on this.
Thanks,
Abhishek
On Wed, Aug 6, 2025 at 5:10 AM Zoltan Chovan <zc...@cloudera.com.invalid>
wrote:
> Hi,
>
> I'm proposing deprecating Java 8 support and establishing Java 17 as the
> minimum required version for Apache Kudu Java components.
>
> Apache Kudu currently supports Java 8+ for both runtime and build
> environments, as documented in our installation and developer guides.
> However, Java 8 reached End of Public Updates in January 2019 and Extended
> Support will end in December 2030. Meanwhile, Java 17 is the current Long
> Term Support (LTS) release and offers significant improvements in
> performance, security, and developer experience.
>
> I opened KUDU-3681 <https://issues.apache.org/jira/browse/KUDU-3681> to
> track this effort, and I already have a patch
> <https://gerrit.cloudera.org/c/23259/> up for review on gerrit.
>
> One of the major changes come from upgrading our Hive dependency, since
> Hive 4.1.0 no longer supports building with Java 8, in turn the Kudu Java
> client wouldn't be buildable with this upgraded dependency either.
>
> I already asked for feedback back in September, however I never received
> any feedback, so I'm attempting to gather some comments again.
>
> If you are a user of the Kudu Java client and this change would affect
> you/your product/your workflow and have any comments or concerns please let
> me know!
>
> Best regards,
> Zoltan
>