Null-safe navigation operator (and elvis operator)

[Remi Forax]

To complement what Joe said, 
Java has chosen to provides a library solution, java.util.Optional, instead of a new language construct. 

so if each of foo(), bar() and baz returns an Optional, you can write: 
foo().flatMap(Main::bar).flatMap(Main::baz) 

The elvis operator works great in a language that tracks nullability like in Kotlin, because if you fail to take care of the possible null, the compiler emits an error. 
The Java type system doesn't track null, introducing the elvis operator will only creates more NPE because the compiler will not fail if you don't use the elvis operator when needed. 
That why we have chosen Optional, because it forces you to deal with the fact that the result may not exist. 

The major drawback of Optional is that people are using it not only as a return type but as a type of a field or in a List, a Map, etc, where it makes no sense but that's another story :) 

regards, 
Rémi 

> De: "joe darcy" <joe.darcy at oracle.com>
> À: "Janis Schöck" <janis at schoeck-netz.de>, "compiler-dev"
> <compiler-dev at openjdk.java.net>
> Envoyé: Mardi 9 Juillet 2019 23:41:59
> Objet: Re: Null-safe navigation operator (and elvis operator)

> Hello Janis,

> We've been aware of the null safe navigator operator, sometimes referred to as
> the Elvis operator, no later than the Project Coin call for proposals back in
> February 2009:

> [ https://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html |
> https://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html ]

> To date, we have chosen not to pursue this change.

> Cheers,

> -Joe
> On 7/9/2019 6:08 AM, Janis Schöck wrote:

>> Hello compiler-dev List,

>> I am trying to assert, whether my idea (which is not actually original it
>> appears) is valuable for Java.
>> Apparently kotlin already features the following (null safe navigation
>> operator):
>> // returns null if... // - foo() returns null, // - or if foo() is non-null, but
>> bar() returns null, // - or if foo() and bar() are non-null, but baz() returns
>> null. // vice versa, return value is non-null if and only if foo(), bar() and
>> baz() are non-null foo () ?. bar () ?. baz ()

>> In that same context, if an expression would evaluate to null, but a primitive
>> type is required, kotlin can
>> fall back on a default, or evaluate an alternate expression.
>> val name : String = maybe ?: "stranger"

>> Independently of kotlin, I think null safe accessing seems to be a valuable
>> language feature. Since I did not
>> know kotlin had this when I started, I put it into a JEP/JSR format to collect
>> feedback on. Since I am new to
>> this list, maybe the primary question: Do I just write up the entire JEP-plain
>> text here, or will this just bother
>> people, as it is a lot of text, and probably will mess up bulked mails?

>> Secondary question: Is this the correct list to write to, or is this better
>> addressed at the amber-project list?

>> Thank you in advance,
>> Janis Schöck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190710/22742283/attachment.html>