Behavior of Switch Statements without fallthrough

[Remi Forax]

----- Original Message -----
> From: "Aaryn Tonita" <atonita at proton.me>
> To: "amber-dev" <amber-dev at openjdk.org>
> Sent: Sunday, July 27, 2025 11:09:14 AM
> Subject: RE: Behavior of Switch Statements without fallthrough

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

Editions in Rust are equivalent to Java versions.

A Java version can break old codes, by example, Java 10 introduces the keyword 'var', so an old code that uses 'var' as a type now behave differently, but we know that there are very few codes (if any) that will use 'var' as a type.

The main reason to not introduce a "real" breaking change* (in Java or in Rust) is to not fracture the ecosystem of libraries,
with some libraries only supporting the old version, others only supporting the new version and libraries trying to support both at the same time (relying on black magic).

Python 2/Python 3 is a good example of what happen if you introduce a breaking change, despite the breaking change occurring more than 17 years ago, my lab is still using apps in Python 2 (because those apps have dependencies that will never be updated to support Python 3).

Java is fundamentally about composition of libraries for free, you can not compose libraries in a fractured ecosystem.

regards,
Rémi