I'm looking forward to Valhalla too, but I think it won't be as impactful as people think. In particular that use case is a poor fit for Valhalla and I don't think Optional will be widely adopted even post-value types. The intent here is to mark which parameters and return types can be null. A laudable goal. However:
1. You will still be using many, many libraries that pre-date cheap Optional. For those, the lack of Optional will NOT indicate the value is always present, it will mean "no optionality information available". Therefore by looking at an API you can't actually tell what the lack of Optional means: it could be deliberate, or it could be legacy. This will make the signal useless.
2. Optional is a very verbose, heavyweight syntax for handling optionality. Therefore some developers will not use it on the grounds that Java is already a very verbose language and it really doesn't need more. This will cause further divergence.
3. Many developers will want to preserve compatibility with old JVMs. Even though Optional is around a long time now, guaranteed cheap/fast Optional will take a long time to roll out and may never make it to Android at all. This will cause some library developers writing high performance code to shun it because null is as cheap as you can possibly get, and universally supported. Again, the lack of Optional will be meaningless.
4. The killer blow: adding Optional changes your function signatures and therefore breaks both binary and source compatibility. Many library developers want to keep a backwards compatible API, or are required to, and that includes for example the Java standard libraries. Therefore lack of Optional will NEVER mean "guaranteed to be present" in most Java code because the standard library won't use it that way.
There is a far, far better way to handle this and it's what Kotlin did:
1. Integrate optionality into the language using lightweight syntax and type inference.
2. Use non-denotable flex-types at the edges, so missing optionality information is added transparently in the source code the first time a developer specifies a type explicitly.
3. Allow annotations to provide nullability information, preserving source and binary compatibility. Integrate it with IDE and compiler data flow analysis. IntelliJ already does this and you can make nullability violations hard errors today by adjusting your project preferences.
4. Finally, allow third party libraries that aren't being changed to be annotated using external annotation files.
1. You will still be using many, many libraries that pre-date cheap Optional. For those, the lack of Optional will NOT indicate the value is always present, it will mean "no optionality information available". Therefore by looking at an API you can't actually tell what the lack of Optional means: it could be deliberate, or it could be legacy. This will make the signal useless.
2. Optional is a very verbose, heavyweight syntax for handling optionality. Therefore some developers will not use it on the grounds that Java is already a very verbose language and it really doesn't need more. This will cause further divergence.
3. Many developers will want to preserve compatibility with old JVMs. Even though Optional is around a long time now, guaranteed cheap/fast Optional will take a long time to roll out and may never make it to Android at all. This will cause some library developers writing high performance code to shun it because null is as cheap as you can possibly get, and universally supported. Again, the lack of Optional will be meaningless.
4. The killer blow: adding Optional changes your function signatures and therefore breaks both binary and source compatibility. Many library developers want to keep a backwards compatible API, or are required to, and that includes for example the Java standard libraries. Therefore lack of Optional will NEVER mean "guaranteed to be present" in most Java code because the standard library won't use it that way.
There is a far, far better way to handle this and it's what Kotlin did:
1. Integrate optionality into the language using lightweight syntax and type inference.
2. Use non-denotable flex-types at the edges, so missing optionality information is added transparently in the source code the first time a developer specifies a type explicitly.
3. Allow annotations to provide nullability information, preserving source and binary compatibility. Integrate it with IDE and compiler data flow analysis. IntelliJ already does this and you can make nullability violations hard errors today by adjusting your project preferences.
4. Finally, allow third party libraries that aren't being changed to be annotated using external annotation files.