Hi folks, https://github.com/apache/iceberg/pull/16881 for the switch expressions changes in Core is merged in. Although, from the discussion in the community sync up today, any similar changes going forward should be in individual PRs and would be at the reviewer's discretion to allow those in.
On Fri, Jun 19, 2026 at 10:45 AM Neelesh Salian <[email protected]> wrote: > Thanks Eduard, Kevin. > I'll file the PRs and tag you for reviews. > > On Wed, Jun 17, 2026 at 10:16 AM Kevin Liu <[email protected]> wrote: > >> Sounds like a great idea. +1 to having separate PRs, might be easier to >> review/rebase. >> >> On Wed, Jun 17, 2026 at 7:27 AM Eduard Tudenhöfner < >> [email protected]> wrote: >> >>> I'm in favor of switching to the new switch expression as it makes the >>> code easier to read. However, I would handle changing *instanceof* >>> stuff in a separate PR. >>> >>> On Wed, Jun 17, 2026 at 1:15 AM Neelesh Salian <[email protected]> >>> wrote: >>> >>>> Hi folks, >>>> >>>> Reviving this with 1.12 on the horizon. I think this is a good time to >>>> do a scoped change. >>>> I'd like to port #15494 <https://github.com/apache/iceberg/pull/15494> >>>> forward >>>> to a fresh PR and drive it for 1.12. Spoke to Max offline and he's agreed. >>>> Manu, I'll fold in anything from #15176 >>>> <https://github.com/apache/iceberg/pull/15176> that's not already >>>> covered. >>>> >>>> Scope is switches and pattern-matching instanceof in iceberg-core, same >>>> as #15494 <https://github.com/apache/iceberg/pull/15494>'s intent. >>>> Text blocks, records, and sealed classes stay "use when appropriate" per >>>> the Java 17 Features thread [1], not in this PR. >>>> >>>> Please let me know if there are any objections to the approach or the >>>> scope. If none, I'll add this to the 1.12 milestone and open the PR. >>>> >>>> Thanks, Neelesh >>>> >>>> [1] https://lists.apache.org/thread/b29jyys3lnr72dbscb5rlg9601c4hbh1 >>>> >>>> >>>> On Fri, Jan 30, 2026 at 6:09 AM Manu Zhang <[email protected]> >>>> wrote: >>>> >>>>> Thanks Peter for opening the discussion. I agree option 2 might work >>>>> for most people. >>>>> We can merge/cherry-pick PRs after cutting the release branch. >>>>> Actually, Intellij IDEA has built-in support for such optimizations so >>>>> it's >>>>> quite easy to rebase/reapply the changes. >>>>> >>>>> Regards, >>>>> Manu >>>>> >>>>> On Fri, Jan 30, 2026 at 6:27 PM Maximilian Michels <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Peter, >>>>>> >>>>>> Thanks for starting the discussion! I'm in favor of making use of Java >>>>>> 17 language. There isn't much we gain from dropping Java 11, if we >>>>>> keep the language target to 11. Features like pattern matching, text >>>>>> blocks, and sealed classes will help us to write cleaner and more >>>>>> maintainable code. >>>>>> >>>>>> Approach (2) seems like a good compromise to minimize the disruption >>>>>> for organizations which backport changes and can't necessarily migrate >>>>>> to a new Java version mid-cycle. The only caveat I see is that some >>>>>> downstream project might not properly support Java 17. For example, we >>>>>> still support Flink 1.20, but Flink only has proper Java 17 support >>>>>> from Flink 2.0 on. >>>>>> >>>>>> Cheers, >>>>>> Max >>>>>> >>>>>> On Fri, Jan 30, 2026 at 9:47 AM Péter Váry < >>>>>> [email protected]> wrote: >>>>>> > >>>>>> > After dropping Java 11, we discussed whether we should start using >>>>>> the newer language features now available to us [1]. The general >>>>>> sentiment >>>>>> was that we should. >>>>>> > >>>>>> > Manu has since opened a large PR [2] that migrates all switch >>>>>> statements to the new switch syntax. While this is a valuable >>>>>> improvement, >>>>>> the size and scope of the change are quite disruptive. This is especially >>>>>> true for other large, ongoing PRs and for teams that maintain internal >>>>>> forks of Iceberg. >>>>>> > >>>>>> > I see three possible ways forward: >>>>>> > >>>>>> > Bite the bullet now and do the migration in one large PR. >>>>>> > Wait until shortly before the release and merge the PR then. This >>>>>> could help organizations that are closely tied to the Apache release >>>>>> cycle >>>>>> but tend to cherry-pick changes mid-cycle. >>>>>> > Apply the new switch syntax incrementally, using it only in new >>>>>> code or when the surrounding code is otherwise being modified. >>>>>> > >>>>>> > My preference would be option 1 or 2. I’m happy to review the code >>>>>> if we decide to proceed in either of those directions, but I’d like to >>>>>> hear >>>>>> others’ thoughts before we make any sweeping changes. >>>>>> > >>>>>> > Thanks, >>>>>> > Peter >>>>>> > >>>>>> > References: >>>>>> > >>>>>> > [1] Dev thread - Java 17 features >>>>>> > https://lists.apache.org/thread/b29jyys3lnr72dbscb5rlg9601c4hbh1 >>>>>> > [2] PR - Replace switch statement with switch expression >>>>>> > https://github.com/apache/iceberg/pull/15176 >>>>>> >>>>>
