Maybe I'm overlooking something, but is there a reason that you can't use Optional#map?

The following example prints nothing, as Optional is short-circuiting in the sense that, if the value inside the Optional doesn't exist (it's null or the Optional is empty), it's treated as empty.

Optional.ofNullable("test")
        .map(s -> null)
        .ifPresent(System.out::println);

For that reason, I'd think you could just do the following:

return Optional.ofNullable(thing)
               .map(x -> x.nullableMethod1(a))
               .map(y -> y.nullableMethod2(b))
               .map(Z::nullableMethod3);

This would map your thing if it exists, or return an empty Optional otherwise.

Naturally, the best person to ask this question is someone on the JCP Executive Committee, not us. However, that won't prevent me from engaging in some idle speculation.

The answer to every "why wasn't this feature implemented" question is always because the benefits did not exceed the costs.

Eric Lippert (former member of the C# team) says that, in order for a product to have a feature, that feature must be:

• thought of in the first place
• desired
• designed
• specified
• implemented
• tested
• documented
• shipped to customers

In other words, there must be many important things that must happen before any new programming language feature can be realized. The costs are larger than you think they are.

On the C# team, every new feature request starts out with a score of minus 100. Then the team evaluates the benefits and the costs, adding points for the benefits, and subtracting points for the costs. If the score doesn't go above zero, the proposed feature is summarily discarded. In other words, the new feature must provide a compelling benefit.

But the Elvis Operator made it into C#. So why didn't it make it into Java?

Despite their apparent similarities, Java and C# have significantly different language philosophies. This is evidenced by the fact that Java enterprise programs tend to be large, structural collections of architecture. Brevity and language expressiveness are sacrificed on the altar of ceremony and ease of coding. Well-known software architectural patterns that everyone on the development team can recognize are preferred over language conveniences.

Consider this Reddit exchange:

The Elvis operator has been proposed for every version of Java since 7, and has been rejected every time. Different languages fall on different points along the spectrum from "pure" to "pragmatic", and languages implementing the Elvis operator do tend to be further toward the pragmatic end of the spectrum than Java.

If you have a team of 15+ year Java pros writing a highly-distributed, highly-concurrent backend processing system of some sort, then you probably want a great degree of architectural rigor.

However, if you have a junior to mid-level team, half of whom migrated from Visual Basic, and you have them writing an ASP.NET web app that mostly just does CRUD operations... then it might be overkill to design a bunch of AbstractFactoryFactory classes to abstract away the fact that you have no control over which columns are nullable in the shitty legacy database that you must use.

These profound differences in language philosophy extend not only to the way the languages are used, but to the way the language design process itself is undertaken. C# is a benevolent dictator language. To get a new feature into C#, you only really have to convince one person: Anders Hejlsberg.

Java takes a more conservative approach. To get a new feature into Java, it must get consensus from a consortium of large vendors such as Oracle, IBM, HP, Fujitsu & Red Hat. Obviously, that process is going to be slower and present a higher bar for new language features.

The question "why wasn't x feature implemented..." always implicitly includes the words, "...if it's obviously such a good idea?" As I have adequately demonstrated here, the choice is never that simple.

Many popular mainstream languages that focus at least somewhat on conciseness have a similar operator, so I'd say that it is fairly common.

First, some notes:

1. For the purposes of this answer, it doesn't matter whether the syntax is ?:, ??, || or or, especially since all are equally concise.
2. What is a "true value" for this operator differs from language to language, and may not be the same as what is considered a "true value" in other contexts (like in an if condition).

Now, let's go though some languages and see what we find:

• C and C++: no Elvis in the standards, since concise syntax sugar does not seem to be focus for these languages
• Java: Elvis was explicitly rejected, seemingly also because syntax sugar is not a focus for Java.
• C#: ?? is a null-checking Elvis
• Python: or works as truthy-checking Elvis
• JavaScript: || works as an Elvis operator that checks for truthiness, ?? is an Elvis operator that only checks for null and undefined
• PHP: ?: is a truthy-checking Elvis, ?? is a null-checking Elvis
• Ruby: || works as a truthy-checking Elvis
• Go: no Elvis, since Go prefers simplicity of language to conciseness of code
• Swift: ?? is a nil-checking Elvis
• Rust: no Elvis, presumably because Rust does not have concepts similar to truthiness or null