Half of the bullet point you find in 75% of all languages (eg int overflow, nullability, race conditions) or are ideas which are a security scientist dream of (eg named arguments).
There is barely something specific to Java and more esoteric.
Overflows are a major source of security vulnerabilities. NULL values are a major source of logic bugs. Data races are the most common bugs in parallel and concurrent applications.
There is no real argument why programming languages as tools should stop at the level of "well you can't put a string into an int".
Is there really a way around this? overflow should be an error in most languages - but isn't for a variety of reasons such as simplifying the construct
c = a + b
In a language without native memory management, it's rare that this type of bug could lead to disclosure of sensitive information. In the cases it would, it's easy enough to guard the overflow with a test such as if (MAX_VAL - b) < a then error.
Chasing safety features which result in difficult to reason about semantics will inevitably lead to low language adoption. I'd be very interested in approaches which guard difficult cases while maintaining ease of use. I'd love a statically typed language which automatically increases the size of numeric type on over/underflow.
> Chasing safety features which result in difficult to reason about semantics will inevitably lead to low language adoption.
Python solves this problem by not having overflow for integers at all, instead all integers are unlimited. It's still one of the most widely used languages in the world.
Haskell has it as well, in a very clever way in my opinion. Number literals don’t have a type themselves, they are inferred to be the correct type based on context/available type notations, etc.
There is both a 64bit integer type and an “infinite” one, and you can change the implementation by a single type notation, in a completely safe way.
And they are mostly niche ideas that in practice gives overly verbose code filled with boilerplate making it just as insecure as languages that take a more pragmatic approach.
> Javascript,
> APIs often do something similar by passing in an object with optional fields*
That's really not the same as the others though, as it's a convention. That's arguing that passing a Python dict or Namespace to a function is the same as named arguments in the function's definition itself. You can do the same in Java with Dictionary<string,object> if you want.
Half of the bullet point you find in 75% of all languages (eg int overflow, nullability, race conditions) or are ideas which are a security scientist dream of (eg named arguments).
There is barely something specific to Java and more esoteric.