Sent email too soon. The decision is to revert the core changes for now.
On Wed, Jun 24, 2026 at 9:35 AM Neelesh Salian <[email protected]> wrote: > 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 >>>>>>> >>>>>>
