Behavior of Switch Statements without fallthrough

[Brian Goetz]

Ethan has this right.  What Aaryn is asking for here is really another 
version of the old "why don't we get rid of all the 'mistakes' and make 
a Java 2" canard.  (Which is surely fun to think about -- though harder 
than you probably think to build consensus on.)






On 7/27/2025 9:48 AM, Ethan McCue wrote:
> > Rust recently moved forward with the idea of editions
>
> Rust added editions a decade ago. Not important, but stuff like that 
> always scores a critical hit on my psyche.
>
> > Why can't Java have something similar?
> > 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.
>
> The problem isn't that doing this is mechanically impossible. There is 
> already a mechanism for compiling for older releases (--release). This 
> is comparable to editions.
>
> The problem is that - while each successive release of the Java 
> language is technically a new and different language - up til now the 
> changes have been largely accretive. Java 25 is not a strict superset 
> of Java 1.1 (Java 1.1 can have assert as an identifier and more), but 
> it almost is. This is what preserves the ship of theseus illusion. If 
> you break this illusion significantly you make a Java2.
>
> Is that worthwhile? Well, there are discussions around null 
> restriction and a "flippening" there, classes being open for extension 
> by default is unideal, and hey while we're at it...
>
> There are many things that you might want to change. Some of these are 
> maybe worthwhile, some maybe not. All changes that make existing code 
> no longer compile need a really good justification.
>
> > switches have no breaks and fall throughs
>
> This one in particular can be achieved via addition, not subtraction. 
> If you don't want to use the switch with fallthrough, do not.
>
> > Is the effort on the compiler team too great?
>
> My outside read of the situation is that this is rarely the case. The 
> implied effort on the part of the wider ecosystem is the greater factor.
>
>
>
> On Sun, Jul 27, 2025 at 6:59 AM Aaryn Tonita <atonita at proton.me> wrote:
>
>     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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250727/c59c79bf/attachment.htm>