Behavior of Switch Statements without fallthrough

[Archie Cobbs]

I'm not convinced that a "Java2"  hard break is a good idea. But for the
sake of argument suppose it was...

Then instead of just declaring a "Java2", a smaller baby step in that
direction would be to define a set of the "best practices" that would
likely constitute such a thing, give it a catchy name like "The Modern Java
Standard", and add a new lint warning flag -Xlint:modern-java  that would
warn about any non-compliant usage.

The key point is that this could be done without anyone (JDK or developer)
having to actually commit to anything. It would just be saying "It's
*possible* in the future that Java might have a hard break from the past
and if you would like to be conformant with that
as-yet-not-fully-decided-and-purely-theoretical-at-this-point possibility
then turn on this flag".

Later in the distant future the feasibility of a real "Java2" could then be
informed by the community's reaction, for example, by surveying how many
projects are being built with -Werror and that lint flag enabled, etc.

-Archie

On Sun, Jul 27, 2025 at 9:59 AM Brian Goetz <brian.goetz at oracle.com> wrote:

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

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250727/9036739b/attachment.htm>