Java and Optional


#1

Are there any plans to add nullable sugar to java.util.Optional? I’m not saying that generated APIs should use them where previously there were nullable return types, but being able to treat Optional values as nullable from other APIs or, when implementing interfaces from those APIs, return a nullable value where an Optional is expected, would be really really really nice.


#2

I don’t think kotlin would benefit from any syntactic sugar for optionals. It would just lead to people using them even though they are inferior to nullables in any regard.
If you have to interface with java code using optionals often you could just create 2 little utility functions

fun <T: Any> T?.asOptional() = Optional<T>.ofNullable(this)
fun <T: Any> Optional<T>.asNullable: T? = this.orElse(null)

#3

I have those already, but it would be nice to not need to use them at all. And I don’t think it would lead to people using them over nullable types - I’m talking just about compatibility. The same way Kotlin has SAM conversions, but not if the interface was defined in Kotlin.


#4

For compatibility you can also annotate your Java code with nullability annotations.


#5

The special language feature for that is absolutely unnecessary. If you are using kotlin, than optional are needless and you are better to remove them from code and replace by nullables. If you are interacting with java code, then functions (I use properties) like the ones shown by @Wasabi375 are quite sufficient.


#6

I could, but this isn’t my Java code, it’s someone else’s.


#7

They might be ‘sufficient’ but Kotlin’s about seamless interfacing with sugar where necessary. For example how MutableList and List are both java.util.List but behave differently.


#8

If you are using Intellij, you can annotate third-party API with external annotations.


#9

Is there a way to distribute that annotated API as part of my library?


#10

I have created a issue on YouTrack asking for this feature. However, there has not been any progress for almost a year now.


#11

Because maximum that could be done is the standard library support for conversion methods or properties. No language changes will be ever done for the feature that requires two additional lines of code for the whole program.


#12

It’s not just a matter of two additional conversion functions — it’s also calling them throughout the code base in places where such conversion is required, which definitely adds some boilerplate.

However making such conversion implicit is not in the spirit of Kotlin, since it avoids having implicit conversions in general.


#13

Maybe there can be an argument for adding an annotation to functions so that the compiler automatically creates overloads with Optionals

@CreateOptionals
fun foo(bar: Int?) {}
// auto generates
fun foo(bar: Optional<Int>) = foo(bar.orElse(null)

However I am not sure how this would work with functions returning a nullable value, because you can’t overload just based on the return type. But I guess there might be some tricks that can be done by renaming the generated function visible to the jvm.
That way at least it would be possible to solve the problem of implementing interfaces using Optionals.


#14

This is the exact opposite of what I’m asking for. I’m not asking for Optionals to be generated for public interfaces, I’m asking for Optionals to be interpreted from Java interfaces as nullables.


#15

What about nullable optionals? I don’t think anyone will actually use it, but it could be done. What about lists of optionals?


#16

An Optional<T>? would just be treated as T?. Null would be the same thing as Optional.empty(). And you can have lists of nullable types, can you not?