<div dir="ltr">> Rust recently moved forward with the idea of editions<br><br>Rust added editions a decade ago. Not important, but stuff like that always scores a critical hit on my psyche.<br><br>> Why can't Java have something similar?<br>> 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.<br><br>The problem isn't that doing this is mechanically impossible. There is already a mechanism for compiling for older releases (<font face="monospace">--release</font><font face="arial, sans-serif">). This is comparable to editions.<br></font><br>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 <font face="monospace">assert</font><font face="arial, sans-serif"> 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.<br></font><br>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...<br><br>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.<br><br>> switches have no breaks and fall throughs<br><br>This one in particular can be achieved via addition, not subtraction. If you don't want to use the switch with fallthrough, do not.<br><br>> Is the effort on the compiler team too great?<br><br>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.<div><br><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Jul 27, 2025 at 6:59 AM Aaryn Tonita <<a href="mailto:atonita@proton.me">atonita@proton.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Since we are talking about deprecation,<br>
<br>
> But it would surely be better to just get to "switches are exhaustive".  To do that, though, some existing code will stop compiling.<br>
<br>
> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Is the effort on the compiler team too great?<br>
</blockquote></div>