Behavior of Switch Statements without fallthrough
Aaryn Tonita
atonita at proton.me
Mon Jul 28 07:36:32 UTC 2025
> "why don't we get rid of all the 'mistakes' and make a Java 2"
Indeed, this is exactly what I wanted to bring up, because unlike
> Python 2/Python 3 is a good example of what happen if you introduce a breaking change
where importing a dependency written in python 2 was generally impossible for the python 3 interpreter, if the breaking change only existed in the Java language the JVM bytecode could save the day and make code interoperable. Rust avoided this by marking crates with the edition and promising to keep compiling old editions and python chose a hard break. Java can avoid it simply by not making breaking changes to the JVM.
In practice,
> add a new lint warning flag -Xlint:modern-java that would warn about any non-compliant usage.
is what is already done but in a fractured and lacklustre manner with additional tools. Static linters add a side channel type checker to analyze null flows using type annotations. Static linters can also forbid usage of dangerous features like switch fallthroughs. But enabling these tools generally requires some maintenance and diligence that is often delayed because it does not come out of the box with javac.
As a developer that enjoys the Java language I don't think of this as a canard so much as a hope. If Java2 can only ever exist as a language with a combination of the Java language itself plus an ad hoc selection of static analysers then other languages with a more out of the box experience become attractive. I see this a little bit in the same grain as the moves towards "paving the onramp": I would love to have a batteries included static analyser or have it directly built into the type system without needing to invest the effort to choose and arrange multiple tools. So having an Oracle/OpenJDK linter would be also great.
On the other hand static analysers are becoming ubiquitous enough that perhaps it is even a basic thing that would be included in every project soon enough. I also can see the social aspect that this kind of backwards compatibility is still a hard break for businesses that would need to "modernise" code that works using features now considered "bad practice"; certainly there is limited patience for that.
More information about the amber-dev
mailing list