The term "safe language" doesn't have a well-defined meaning, but the closest one that can be used in a binary context is "a language that doesn't have undefine

The term "safe language" doesn't have a well-defined meaning, but the closest one that can be used in a binary context is "a language that doesn't have undefined behaviour." This definition is also flawed and often misleading, but is quite traditional and widely used, and by that definition, Java is a "safe language." What the author means is that there are languages that can catch more bugs than Java. That is true, but there are languages that can catch more bugs than, say, Rust, too. > Java does not trap overflows True, or at least the built-in operators don't. However, unlike in C/C++, their behaviour is well defined under all conditions, and a lot of code depends on this behaviour. The operations that do trap overflows require opt-in through the Math class. > Java allows data races True, but in this case it's unclear if the cure is worse than the disease or not. Preventing some bugs in the language come with a real cost, and so what matters is the overall cost of avoiding a bug. We can look at three languages that address this problem — Erlang, Clojure, and Rust — and they all pay a price for that. The first two in performance and the last in language complexity. > Java lacks null safety. True, but I think this is fixable, and hope it will be addressed. There's ongoing research. > Java lacks named arguments This one is complicated. For one, watch for records, which are on their way of getting named arguments and will be able to address the instances of "lots of parameters." For another, Java's excellent IDE's all do show the parameter type alongside the positional argument. Finally, Java is not just a language but also a platform that is built to support separate compilation. Named arguments would make parameter names part of the ABI, and would make it more complicated and harder for units to evolve in a backward compatible way. Binary backward compatibility is a very useful property, and so the benefit of named argument (for all methods) probably does not justify their cost (records have specific constraints that could allow their compatible evolution while still supporting named arguments).