Ask me about using a Java library that could return an option type, which could be null, so you have to check for both the None return value AS WELL AS null.
No, you don't -- because those are two different kinds of null!
If your library's function returns Optional.empty(), then it's because it successfully returned no value. If it returns null, though, then the library has a bug and you should crash instead of trying to continue in a known invalid state.
Without the Optional type signature, the function would return null for both of these, and your program will appear to work even though it's just suffered a bug.
I'm not sure I agree with that. See how MS did that in C# 7:
https://www.kenneth-truyers.net/2016/01/25/new-features-in-c...
https://wiki.openjdk.java.net/display/valhalla/Minimal+Value...
Until then it is an issue that we have to live with.
Just one example: Java's type erasure trick does not work anymore when value types are type parameters, so it affects the build process. The current approach seems to be to construct specific instances at run time (or rather at class loader time). That is very late though, because some information (like return types) are lost after compilation.
The ongoing changes related to value types, AOT compilation, and overall mechanical sympathy are driven from pressure in the Fintech industry. Which has been moving into Java during the last decade, and currently is eyeing other stacks that could given them the benefits of Java alongside those features, like e.g. Pony.
So of course Oracle wants Java to stay relevant in those domains.
You are required to annotate type parameters for the old reference behavior, currently that would be with the any modifier.
Something like
class Data<any T> {
}