Behavior of Switch Statements without fallthrough
Aaryn Tonita
atonita at proton.me
Sun Jul 27 09:09:14 UTC 2025
Since we are talking about deprecation,
> But it would surely be better to just get to "switches are exhaustive". To do that, though, some existing code will stop compiling.
> Now for an absurd statement. Can we deprecate the C-style switch? I understand why it cannot be done, no need to think of me as delusional, but can we at least send out an alert warning developers to avoid the old switch statement.
Doesn't Java benefit more than other languages here? Rust recently moved forward with the idea of editions where legacy code would continue to compile with an older edition of the language. The compiler would still get better in time, (they wouldn't be stuck on an older compiler) and the code would be importable from newer editions.
Why can't Java have something similar? The benefit Java has is that it targets the JVM (ok, rust targets LLVM IR) and an older edition can compile to the latest version of the bytecode if the compiler supported it. The language breaking features aren't necessarily JVM breakage.
Old code could compile, developers could bugfix and update to latest compiler versions without breaking their existing code, but if they want to modernize their Java, then the code breaks but they have decided to put in the effort.
I would love to have such a breaking change where implicit null is gone, where arrays require initialization, where switches have no breaks and fall throughs. Where my old code continues to compile on the latest compiler but on an older edition of the language.
Is the effort on the compiler team too great?
More information about the amber-dev
mailing list