There is not one single definition of safe, as perfect safety does not exist. So Java being 'safe' depends on the definition Apart from the integer overflows t

There is not one single definition of safe, as perfect safety does not exist. So Java being 'safe' depends on the definition Apart from the integer overflows the other three are IMHO reasonable, not surprising, known to everyone, and manageable. * Data races: no, the Java compiler will not try to construct a proof of data-race-free behavior. Instead there are some tools: immutability, java.util.concurrent.*, lock checkers libraries [1] if you want something a la rust, actors, execution pools, futures, atomics. * Null safety: Some annotations can deal with that. * Named arguments: IDEs (IntelliJ does) now show parameter names of the method to the programmer. All in all, the arguments presented are weak IMHO and Java is pretty safe, and offers pretty good performance with this safety definition. As for data leaks, I'll steal a comment from Lemire's site: “Memory leaks are memory safe in Rust” [1] https://checkerframework.org/manual/#lock-checker https://checkerframework.org/manual/#lock-checker