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 >>> >>
