<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">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.)<br>
<br>
<br>
<br>
<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 7/27/2025 9:48 AM, Ethan McCue
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CA+NR86gUhReKub-Ss9atH_r+Fw1zTMpoAd8erz9t0m8TDvLCSw@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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>
</blockquote>
<br>
</body>
</html>