Would it be nice if the compiler allowed zeros if the <Object> option is expected as an argument?

Question

It would be so obvious that I am starting to think that I lack the rationale to avoid this, as I am sure that Oracle would do just that. This would be the most valuable feature for the Optional for me.

public class TestOptionals{ public static void main(String[] args) { test(null); } public static void test(Optional<Object> optional){ System.out.println(optional.orElse(new DefaultObject())); } } 

(This throws a NullPointerException)

Without this function, I see too verbose using the option for an argument. I prefer the simple signature of Object optional and checking if (null = optional) by creating an object. Not necessary for comparison later. It doesn’t matter if it doesn’t help you check the null value

Answer 1

A HUGE Optional was discussed on all Java mailing lists containing hundreds of posts. Do an online search

 site:mail.openjdk.java.net optional 

and you will get links to many of them. Of course, I can’t even summarize all the issues raised. There was a lot of controversy, and there was quite a lot of opinion about how much “optionality” should be added to the platform. Some people thought that a library solution should not be added at all; some people thought the library solution was useless without language support; some people thought the library’s solution was fine, but there was a huge amount of chatter about what should be in it; and so on. See this post from Brian Goetz on the lambda-dev mailing list for some perspective.

One pragmatic decision of the lambda command was that any optional function cannot include any language changes. The language and compiler teams already had their hands with the lambda and default methods. These, of course, are the top priorities. In practice, the choice was to add Optional as a library class or not to use it at all.

Of course, people knew about the type systems of other languages ​​that support option types. This would be a big change for a system like Java. The fact is that for most of the past 20 years, reference types have been nullified, and there was one untyped null value. Changing this is a huge deal. Perhaps this cannot be done in a compatible way. I am not a specialist in this field, but most of these discussions tend to weed quite quickly.

A smaller change, which may be more acceptable (also mentioned by Marco Topolnik ), should consider the relationship between reference types and Optional as one of the boxes; then add autoboxing / autounboxing support that already exists in the language.

This is already somewhat problematic. When automatic (un) boxing was added in Java 5, it did a lot of things much nicer, but added a lot of rough edges to it. For example, when unpacking automatically, you can now use < and > to compare the values ​​of boxed Integer objects. Unfortunately, using == still compares links instead of values! Boxing also complicated overload; This is one of the most difficult areas of the language today.

Now consider the automatic (un) box between reference types and Optional types. This will allow you to do:

 Optional<String> os1 = "foo"; Optional<String> os2 = null; 

In this code, os1 will end as a string value in the box, and os2 will end as an empty Optional. So far, so good. Now the opposite:

 String s1 = os1; String s2 = os2; 

Now s1 will get the unboxed "foo" , and s2 will be unpacked to null , I think. But the Optional point was to make this unboxing explicit so that programmers would have to decide what to do with an empty Optional , instead of just turning it into null .

Hmmm, so maybe just do Autoboxing Optional , but not autounboxing. Let's get back to the case of using OP:

 public static void main(String[] args) { test(null); } public static void test(Optional<Object> optional) { System.out.println(optional.orElse(new DefaultObject())); } 

If you really want to use Optional , you can manually install it on one line:

 public static void test(Object arg) { Optional<Object> optional = Optional.ofNullable(arg); System.out.println(optional.orElse(new DefaultObject())); } 

Obviously, it would be better if you did not have to write this, but to save this line of code would require a huge amount of work with the language / compiler and the risk of compatibility. Is it really worth it?

This seems to mean that it will allow the caller to go null in order to have a specific value for the called party, for example, "use the default object." In small examples, this seems fine, but overall, loading semantics on null more and more seems like a bad idea. Thus, this is an additional reason not to add specific language support for null boxing. The Optional.ofNullable() method basically consists in closing the gap between code that uses null and code that uses Optional .

Answer 2

If you intend to use an extra class, see other answers.

On the other hand, I interpreted your question like this: "Would it be a good idea to avoid syntactic overhead when using Optional, while maintaining the guarantee of no null pointers in your code?" The answer to this question is a resounding yes. Fortunately, Java has a feature, type annotation, that allows this. This does not require the use of the Option class.

You can get the same compile-time guarantees without adding Optional to your code and maintaining backward compatibility with existing code.

• Annotate links that may be empty with type @Nullable annotations.
• Launch a compiler plugin like Checker Framework Nullness Checker .

If the plugin does not throw any errors, then you know that your code always checks for a null value, and therefore, your code never throws a null pointer exception exception at runtime.

The plugin handles special cases mentioned by @immibis etc., so your code is much less verbose than the code using the option. The plugin is compatible with regular Java code and does not require the use of Java 8, as the option does. It is used daily at companies like Google.

Note that for this approach, you need to provide a command line argument to the compiler in order to tell it to run the plugin. Also note that this approach does not integrate with the option; this is an alternative approach.