You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iceberg.apache.org by Péter Váry <pe...@gmail.com> on 2026/01/13 17:39:05 UTC
Java 17 features
Since we are moving to Java 17 and dropping Java 11 support, we can start
taking advantage of the language features introduced in Java 17.
Some notable examples include:
1. *Pattern Matching for instanceof *– Simplifies type checks by
allowing variable binding directly in the condition (e.g., if (obj
instanceof String s)), removing the need for manual casting.
2. *Switch Expressions* – Extend switch with an expression form that
returns a value, uses the arrow (->) syntax, prevents fall‑through by
default, and eliminates the need for break statements.
3. *Text Blocks* – Multi-line string literals using triple quotes ("""),
making embedded JSON, SQL, and similar content far easier to read and
maintain.
4. *Records* – A restricted class type designed to represent immutable
data carriers. Records automatically generate constructors, accessors, and
implementations of equals(), hashCode(), and toString(), substantially
reducing boilerplate for DTO‑style objects.
5. *Sealed Classes and Interfaces* – These allow us to explicitly
control which classes or interfaces may extend or implement a given type,
enabling clearer and more maintainable inheritance hierarchies.
I think we should begin using some of these features—specifically pattern
matching, switch expressions, and text blocks—in new code whenever
appropriate.
I’m less convinced about adopting records due to their limitations around
inheritance and extensibility, and I don’t currently have a strong opinion
on sealed classes.
Does anyone have concerns about adopting any of these features?
Thanks,
Peter
Re: Java 17 features
Posted by Alexandre Dutra <ad...@apache.org>.
In my opinion, Java – not Guava :-) – Immutables is still a valuable
library. Records are OK for small usages, but they don't give you
builders, copy methods, validation methods, etc. out of the box.
On Tue, Jan 13, 2026 at 7:17 PM Russell Spitzer
<ru...@gmail.com> wrote:
>
> Do we still need Guava Immutables now that we have records?
>
> On Tue, Jan 13, 2026 at 12:14 PM Anton Okolnychyi <ao...@gmail.com> wrote:
>>
>> I am using most of these for the upcoming Spark 4.1 integration and I find them useful. I think we should embrace these concepts throughout the code for new development.
>>
>> - Anton
>>
>> вт, 13 січ. 2026 р. о 09:40 Péter Váry <pe...@gmail.com> пише:
>>>
>>> Since we are moving to Java 17 and dropping Java 11 support, we can start taking advantage of the language features introduced in Java 17.
>>>
>>> Some notable examples include:
>>>
>>> Pattern Matching for instanceof – Simplifies type checks by allowing variable binding directly in the condition (e.g., if (obj instanceof String s)), removing the need for manual casting.
>>> Switch Expressions – Extend switch with an expression form that returns a value, uses the arrow (->) syntax, prevents fall‑through by default, and eliminates the need for break statements.
>>> Text Blocks – Multi-line string literals using triple quotes ("""), making embedded JSON, SQL, and similar content far easier to read and maintain.
>>> Records – A restricted class type designed to represent immutable data carriers. Records automatically generate constructors, accessors, and implementations of equals(), hashCode(), and toString(), substantially reducing boilerplate for DTO‑style objects.
>>> Sealed Classes and Interfaces – These allow us to explicitly control which classes or interfaces may extend or implement a given type, enabling clearer and more maintainable inheritance hierarchies.
>>>
>>> I think we should begin using some of these features—specifically pattern matching, switch expressions, and text blocks—in new code whenever appropriate.
>>> I’m less convinced about adopting records due to their limitations around inheritance and extensibility, and I don’t currently have a strong opinion on sealed classes.
>>>
>>> Does anyone have concerns about adopting any of these features?
>>>
>>> Thanks,
>>> Peter
Re: Java 17 features
Posted by Russell Spitzer <ru...@gmail.com>.
Do we still need Guava Immutables now that we have records?
On Tue, Jan 13, 2026 at 12:14 PM Anton Okolnychyi <ao...@gmail.com>
wrote:
> I am using most of these for the upcoming Spark 4.1 integration and I find
> them useful. I think we should embrace these concepts throughout the code
> for new development.
>
> - Anton
>
> вт, 13 січ. 2026 р. о 09:40 Péter Váry <pe...@gmail.com> пише:
>
>> Since we are moving to Java 17 and dropping Java 11 support, we can start
>> taking advantage of the language features introduced in Java 17.
>>
>> Some notable examples include:
>>
>> 1. *Pattern Matching for instanceof *– Simplifies type checks by
>> allowing variable binding directly in the condition (e.g., if (obj
>> instanceof String s)), removing the need for manual casting.
>> 2. *Switch Expressions* – Extend switch with an expression form that
>> returns a value, uses the arrow (->) syntax, prevents fall‑through by
>> default, and eliminates the need for break statements.
>> 3. *Text Blocks* – Multi-line string literals using triple quotes
>> ("""), making embedded JSON, SQL, and similar content far easier to read
>> and maintain.
>> 4. *Records* – A restricted class type designed to represent
>> immutable data carriers. Records automatically generate constructors,
>> accessors, and implementations of equals(), hashCode(), and toString(),
>> substantially reducing boilerplate for DTO‑style objects.
>> 5. *Sealed Classes and Interfaces* – These allow us to explicitly
>> control which classes or interfaces may extend or implement a given type,
>> enabling clearer and more maintainable inheritance hierarchies.
>>
>> I think we should begin using some of these features—specifically pattern
>> matching, switch expressions, and text blocks—in new code whenever
>> appropriate.
>> I’m less convinced about adopting records due to their limitations around
>> inheritance and extensibility, and I don’t currently have a strong opinion
>> on sealed classes.
>>
>> Does anyone have concerns about adopting any of these features?
>>
>> Thanks,
>> Peter
>>
>
Re: Java 17 features
Posted by Anton Okolnychyi <ao...@gmail.com>.
I am using most of these for the upcoming Spark 4.1 integration and I find
them useful. I think we should embrace these concepts throughout the code
for new development.
- Anton
вт, 13 січ. 2026 р. о 09:40 Péter Váry <pe...@gmail.com> пише:
> Since we are moving to Java 17 and dropping Java 11 support, we can start
> taking advantage of the language features introduced in Java 17.
>
> Some notable examples include:
>
> 1. *Pattern Matching for instanceof *– Simplifies type checks by
> allowing variable binding directly in the condition (e.g., if (obj
> instanceof String s)), removing the need for manual casting.
> 2. *Switch Expressions* – Extend switch with an expression form that
> returns a value, uses the arrow (->) syntax, prevents fall‑through by
> default, and eliminates the need for break statements.
> 3. *Text Blocks* – Multi-line string literals using triple quotes
> ("""), making embedded JSON, SQL, and similar content far easier to read
> and maintain.
> 4. *Records* – A restricted class type designed to represent immutable
> data carriers. Records automatically generate constructors, accessors, and
> implementations of equals(), hashCode(), and toString(), substantially
> reducing boilerplate for DTO‑style objects.
> 5. *Sealed Classes and Interfaces* – These allow us to explicitly
> control which classes or interfaces may extend or implement a given type,
> enabling clearer and more maintainable inheritance hierarchies.
>
> I think we should begin using some of these features—specifically pattern
> matching, switch expressions, and text blocks—in new code whenever
> appropriate.
> I’m less convinced about adopting records due to their limitations around
> inheritance and extensibility, and I don’t currently have a strong opinion
> on sealed classes.
>
> Does anyone have concerns about adopting any of these features?
>
> Thanks,
> Peter
>
Re: Java 17 features
Posted by Maximilian Michels <mx...@apache.org>.
We seem to be in agreement here on using Java 17 features. We already
switched to Java 17 via https://github.com/apache/iceberg/pull/14400.
I noticed iceberg-core currently has 257 warnings related to Java 17
features. All the warnings are related to switch statements and casts
after instanceof checks. Here is a PR to fix those:
https://github.com/apache/iceberg/pull/15494
Cheers,
Max
On Wed, Jan 14, 2026 at 12:22 PM Eduard Tudenhöfner
<et...@apache.org> wrote:
>
> I'm generally in favor of adopting JDK 17 features
>
> On Wed, Jan 14, 2026 at 11:23 AM Péter Váry <pe...@gmail.com> wrote:
>>
>> From my experience, records work well for internal structures. However, since they are effectively immutable and difficult to evolve, they are not ideal as input or output parameters for API methods.
>>
>> Steve Loughran <st...@cloudera.com> ezt írta (időpont: 2026. jan. 13., K, 22:54):
>>>
>>>
>>>
>>> On Tue, 13 Jan 2026 at 17:39, Péter Váry <pe...@gmail.com> wrote:
>>>>
>>>> Since we are moving to Java 17 and dropping Java 11 support, we can start taking advantage of the language features introduced in Java 17.
>>>>
>>>> Some notable examples include:
>>>>
>>>> Pattern Matching for instanceof – Simplifies type checks by allowing variable binding directly in the condition (e.g., if (obj instanceof String s)), removing the need for manual casting.
>>>> Switch Expressions – Extend switch with an expression form that returns a value, uses the arrow (->) syntax, prevents fall‑through by default, and eliminates the need for break statements.
>>>
>>> powerful, saves on code and reduce risk of errors through accidental fall through.
>>>>
>>>> Text Blocks – Multi-line string literals using triple quotes ("""), making embedded JSON, SQL, and similar content far easier to read and maintain.
>>>
>>>
>>> these are wonderful, especially for writing tests, though the indentation rules are a bit subtle https://docs.oracle.com/en/java/javase/17/text-blocks/index.html
>>>
>>>> Records – A restricted class type designed to represent immutable data carriers. Records automatically generate constructors, accessors, and implementations of equals(), hashCode(), and toString(), substantially reducing boilerplate for DTO‑style objects.
>>>
>>> good for simple abstract data types; no experience in bigger roles.
>>>>
>>>> Sealed Classes and Interfaces – These allow us to explicitly control which classes or interfaces may extend or implement a given type, enabling clearer and more maintainable inheritance hierarchies.
>>>
>>> These are probably the most conceptually complex and hardest to get right. And I don't know what happens across versions (sealing something which wasn't before, changing subclass attributes). Best to assume it is like adding final or abstract to a class: you can break all subclasses.
>>>
>>>>
>>>> I think we should begin using some of these features—specifically pattern matching, switch expressions, and text blocks—in new code whenever appropriate.
>>>> I’m less convinced about adopting records due to their limitations around inheritance and extensibility, and I don’t currently have a strong opinion on sealed classes.
>>>>
>>>> Does anyone have concerns about adopting any of these features?
>>>>
>>>>
>>>
>>> No, except for any large scale use of sealed. It'll take time to get right, and while the examples all assume you are putting the classes into the same module, in open source you don't get that ability to control what sneaks into your packages and modules -sometimes because they have to (example, spark almost mandating it [spark] packaging for complex use).
Re: Java 17 features
Posted by Eduard Tudenhöfner <et...@apache.org>.
I'm generally in favor of adopting JDK 17 features
On Wed, Jan 14, 2026 at 11:23 AM Péter Váry <pe...@gmail.com>
wrote:
> From my experience, records work well for internal structures. However,
> since they are effectively immutable and difficult to evolve, they are not
> ideal as input or output parameters for API methods.
>
> Steve Loughran <st...@cloudera.com> ezt írta (időpont: 2026. jan. 13.,
> K, 22:54):
>
>>
>>
>> On Tue, 13 Jan 2026 at 17:39, Péter Váry <pe...@gmail.com>
>> wrote:
>>
>>> Since we are moving to Java 17 and dropping Java 11 support, we can
>>> start taking advantage of the language features introduced in Java 17.
>>>
>>> Some notable examples include:
>>>
>>> 1. *Pattern Matching for instanceof *– Simplifies type checks by
>>> allowing variable binding directly in the condition (e.g., if (obj
>>> instanceof String s)), removing the need for manual casting.
>>> 2. *Switch Expressions* – Extend switch with an expression form that
>>> returns a value, uses the arrow (->) syntax, prevents fall‑through by
>>> default, and eliminates the need for break statements.
>>>
>>> powerful, saves on code and reduce risk of errors through accidental
>> fall through.
>>
>>>
>>> 1. *Text Blocks* – Multi-line string literals using triple quotes
>>> ("""), making embedded JSON, SQL, and similar content far easier to read
>>> and maintain.
>>>
>>>
>> these are wonderful, especially for writing tests, though the indentation
>> rules are a bit subtle
>> https://docs.oracle.com/en/java/javase/17/text-blocks/index.html
>>
>>
>>> 1. *Records* – A restricted class type designed to represent
>>> immutable data carriers. Records automatically generate constructors,
>>> accessors, and implementations of equals(), hashCode(), and toString(),
>>> substantially reducing boilerplate for DTO‑style objects.
>>>
>>> good for simple abstract data types; no experience in bigger roles.
>>
>>>
>>> 1. *Sealed Classes and Interfaces* – These allow us to explicitly
>>> control which classes or interfaces may extend or implement a given type,
>>> enabling clearer and more maintainable inheritance hierarchies.
>>>
>>> These are probably the most conceptually complex and hardest to get
>> right. And I don't know what happens across versions (sealing something
>> which wasn't before, changing subclass attributes). Best to assume it is
>> like adding final or abstract to a class: you can break all subclasses.
>>
>>
>>> I think we should begin using some of these features—specifically
>>> pattern matching, switch expressions, and text blocks—in new code whenever
>>> appropriate.
>>> I’m less convinced about adopting records due to their limitations
>>> around inheritance and extensibility, and I don’t currently have a strong
>>> opinion on sealed classes.
>>>
>>> Does anyone have concerns about adopting any of these features?
>>>
>>>
>>>
>> No, except for any large scale use of sealed. It'll take time to get
>> right, and while the examples all assume you are putting the classes into
>> the same module, in open source you don't get that ability to control what
>> sneaks into your packages and modules -sometimes because they have to
>> (example, spark almost mandating it [spark] packaging for complex use).
>>
>
Re: Java 17 features
Posted by Péter Váry <pe...@gmail.com>.
From my experience, records work well for internal structures. However,
since they are effectively immutable and difficult to evolve, they are not
ideal as input or output parameters for API methods.
Steve Loughran <st...@cloudera.com> ezt írta (időpont: 2026. jan. 13., K,
22:54):
>
>
> On Tue, 13 Jan 2026 at 17:39, Péter Váry <pe...@gmail.com>
> wrote:
>
>> Since we are moving to Java 17 and dropping Java 11 support, we can start
>> taking advantage of the language features introduced in Java 17.
>>
>> Some notable examples include:
>>
>> 1. *Pattern Matching for instanceof *– Simplifies type checks by
>> allowing variable binding directly in the condition (e.g., if (obj
>> instanceof String s)), removing the need for manual casting.
>> 2. *Switch Expressions* – Extend switch with an expression form that
>> returns a value, uses the arrow (->) syntax, prevents fall‑through by
>> default, and eliminates the need for break statements.
>>
>> powerful, saves on code and reduce risk of errors through accidental fall
> through.
>
>>
>> 1. *Text Blocks* – Multi-line string literals using triple quotes
>> ("""), making embedded JSON, SQL, and similar content far easier to read
>> and maintain.
>>
>>
> these are wonderful, especially for writing tests, though the indentation
> rules are a bit subtle
> https://docs.oracle.com/en/java/javase/17/text-blocks/index.html
>
>
>> 1. *Records* – A restricted class type designed to represent
>> immutable data carriers. Records automatically generate constructors,
>> accessors, and implementations of equals(), hashCode(), and toString(),
>> substantially reducing boilerplate for DTO‑style objects.
>>
>> good for simple abstract data types; no experience in bigger roles.
>
>>
>> 1. *Sealed Classes and Interfaces* – These allow us to explicitly
>> control which classes or interfaces may extend or implement a given type,
>> enabling clearer and more maintainable inheritance hierarchies.
>>
>> These are probably the most conceptually complex and hardest to get
> right. And I don't know what happens across versions (sealing something
> which wasn't before, changing subclass attributes). Best to assume it is
> like adding final or abstract to a class: you can break all subclasses.
>
>
>> I think we should begin using some of these features—specifically pattern
>> matching, switch expressions, and text blocks—in new code whenever
>> appropriate.
>> I’m less convinced about adopting records due to their limitations around
>> inheritance and extensibility, and I don’t currently have a strong opinion
>> on sealed classes.
>>
>> Does anyone have concerns about adopting any of these features?
>>
>>
>>
> No, except for any large scale use of sealed. It'll take time to get
> right, and while the examples all assume you are putting the classes into
> the same module, in open source you don't get that ability to control what
> sneaks into your packages and modules -sometimes because they have to
> (example, spark almost mandating it [spark] packaging for complex use).
>
Re: Java 17 features
Posted by Steve Loughran <st...@cloudera.com>.
On Tue, 13 Jan 2026 at 17:39, Péter Váry <pe...@gmail.com>
wrote:
> Since we are moving to Java 17 and dropping Java 11 support, we can start
> taking advantage of the language features introduced in Java 17.
>
> Some notable examples include:
>
> 1. *Pattern Matching for instanceof *– Simplifies type checks by
> allowing variable binding directly in the condition (e.g., if (obj
> instanceof String s)), removing the need for manual casting.
> 2. *Switch Expressions* – Extend switch with an expression form that
> returns a value, uses the arrow (->) syntax, prevents fall‑through by
> default, and eliminates the need for break statements.
>
> powerful, saves on code and reduce risk of errors through accidental fall
through.
>
> 1. *Text Blocks* – Multi-line string literals using triple quotes
> ("""), making embedded JSON, SQL, and similar content far easier to read
> and maintain.
>
>
these are wonderful, especially for writing tests, though the indentation
rules are a bit subtle
https://docs.oracle.com/en/java/javase/17/text-blocks/index.html
> 1. *Records* – A restricted class type designed to represent immutable
> data carriers. Records automatically generate constructors, accessors, and
> implementations of equals(), hashCode(), and toString(), substantially
> reducing boilerplate for DTO‑style objects.
>
> good for simple abstract data types; no experience in bigger roles.
>
> 1. *Sealed Classes and Interfaces* – These allow us to explicitly
> control which classes or interfaces may extend or implement a given type,
> enabling clearer and more maintainable inheritance hierarchies.
>
> These are probably the most conceptually complex and hardest to get right.
And I don't know what happens across versions (sealing something which
wasn't before, changing subclass attributes). Best to assume it is like
adding final or abstract to a class: you can break all subclasses.
> I think we should begin using some of these features—specifically pattern
> matching, switch expressions, and text blocks—in new code whenever
> appropriate.
> I’m less convinced about adopting records due to their limitations around
> inheritance and extensibility, and I don’t currently have a strong opinion
> on sealed classes.
>
> Does anyone have concerns about adopting any of these features?
>
>
>
No, except for any large scale use of sealed. It'll take time to get right,
and while the examples all assume you are putting the classes into the same
module, in open source you don't get that ability to control what sneaks
into your packages and modules -sometimes because they have to (example,
spark almost mandating it [spark] packaging for complex use).