Behavior of Switch Statements without fallthrough

[Johannes Spangenberg]

Just changing the behavior of switch would be problematic because it 
could silently change the behavior of the code. Not every developer who 
switches to a new version of the language reads all the release notes. 
It might also be tricky to find all places which would need to be 
adjusted. If some code did compile before, and it continues to compile 
now, it should not suddenly do something different.

Anyway, you could of course still introduce an entirely new syntax and 
deprecate or even disable the old syntax. But that is kind of what 
happens with switch statements, except that the old syntax is not 
deprecated.

At the end, it is balance. If you make too many changes too often, it 
can become annoying for people maintaining a large amount of code. It 
can also make it harder to google your problems as the answers may 
depend on the version of the language. As a result, it makes the 
language more complex as long as you haven't eliminated the old code 
from the ecosystem, which can take decades.

I don't know what the right balance is. Historically, I think Java was 
rather successful by staying conservative. I remember having read a lot 
of backlash for the breaking changes in Java 17, however these changes 
were mostly in the JVM and not in the language.

> 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).

I think the topic was only about breaking the language, not the JVM. Old 
code should keep working as long as it is compiled against a previous 
language version (--release).

> I'm not convinced that a "Java2"  hard break is a good idea. But for 
> the sake of argument suppose it was... Then [...] a smaller baby step 
> in that direction would be to define a set of the "best practices" 
> [...], and add a new lint warning flag

I think Java should definitely consider deprecating old language 
features in the future. Otherwise, the language complexity will only 
grow over time. Such change in the ecosystem would take decades, but if 
new language features are added, designers should try if they can make 
old features obsolete eventually.

Regards,
Johannes