2

I read Why should Java 8's Optional not be used in arguments . But what about Optional(Int|Long|Double), are any arguments against usage of them as input argument?

As I understand correctly, they can not be not empty, but with null (the main argument argument against Optional<X> in input parameters), but may be there are other reefs? Should I use OptionalInt or Integer with null and not null value?

user1244932
  • 7,352
  • 5
  • 46
  • 103

2 Answers2

10

This idea of not using Optionals as method parameters is not only specific to Optional<T> but all type of Optionals.

When you say:

As I understand correctly, they can not be not empty, but with null (the main argument argument against Optional<X> in input parameters)

First and foremost let's just get the terminology correct, when an Optional<X> contains a non-null reference we say that it's present else we say the Optional<X> is empty or absent. you shouldn't say an Optional<X> contains null.

All Optionals can be empty regardless of whether it's a container for an object of type T or primitive types.

for example, if you peek into the OptionalInt class documentation, it says:

A container object which may or may not contain a int value. If a value is present, isPresent() will return true and getAsInt() will return the value.

Emphasis mine.

When the Optional does not contain an int value then it's an empty Optional.

Should I use OptionalInt or Integer with null and not null value?

As for using OptionalInt or Integer really depends on your use case.

  • Like all Optional's both for a container of type T and primitive types they're descriptive and enable one to apply different type of operations to extract the value if present or do something else if absent.
  • Any Integer field can be assigned the value null.
  • One can return null in any method having Integer as the return type.
  • OptionalInt fields (controversial) should never be assinged null as that defeats the whole purpose of using Optional in the first place.
  • One should never return null in any method having the return type OptionalInt again as it defeats the whole purpose of using Optional in the first place.

etc..

Further, some people actually discourage the use of primitive Optionals simply because they lack the map, flatMap, and filter methods.

Essentially, there's no rule to always use Optionals or vice vera, instead pick the API that best fits your needs.

Ousmane D.
  • 54,915
  • 8
  • 91
  • 126
  • 2
    ...and they don’t have `null`, even if passed that. They are empty and will explode if you attempt to get the value – Bohemian Jul 30 '18 at 23:35
  • I can not understand you `Optional` can be `! isPresent`, `isPresent` but `null`, and `isPresent(` and `!= null`, but `OptionalInt` can not be `isPresent` and `null`, because of primitve type can not be `null` – user1244932 Jul 30 '18 at 23:37
  • 7
    @user1244932 "`Optional` can be `isPresent` but null" -- No it can't. The value of the `Optional`, if present, is non-null. See [javadoc](https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html) -- "A container object which may or may not contain a **non-null** value." – khelwood Jul 30 '18 at 23:39
  • @Aomine no intention what so ever to step on your answers, just adding a bit more info... – Eugene Jul 31 '18 at 09:08
  • completely fine @Eugene ;), we should have as many helpful answers as possible!. – Ousmane D. Jul 31 '18 at 09:34
3

So there are 3 things to consider, passing an OptionalInt, Integer or int to a method (or having a property in your class of this type).

Usually passing an Integer is not the best idea, since you would need to check against null. Some people actually want that, well mostly for Boolean as it can denote 3 states - unknown/true/false - I still don't like it (an enum is far more suited in this case).

So semantically passing a null to a method that accepts an Integer could mean - I don't want this value to be present. But then, the code providing such a method should be responsible to handle this; a better approach is to have overloaded methods that do not take it as input as such - thus making it clear IMO that this parameter is not mandatory to begin with.

OK, so is passing an int better? Yes, sort of. Think ORM (hibernate) for a second; there are cases when a certain property could be either int or Integer - in this case I favor Integer; mainly because int has a a default value or zero - and I would prefer code to fail with a NullPointer instead of keeping stale values: zero could be a perfectly valid business value, but what if we did not mean to put it as zero? Of course, this means that the DB and Service Layer needs proper validation, etc - I am not going into these details.

So what about passing a OptionalInt to a method that previously was accepting an Integer? You would still have to check for the presence of it (is it null?), you would still have to check if it is empty or not and take according steps. And that usually means that you want different code paths depending on that parameter - in which case something more descriptive must be passed in. You could still do it, but what if in time, you will need one more condition? OptionalInt can't handle that, so a major refactoring would need to take place.

But Optional are awesome as return types. If a method returns an Integer how many times have you checked if it's actually null? On the other hand if a method returns OptionalInt you have to think what to do in case it is missing, because otherwise you can not retrieve it's value: unless isPresent? or any other methods like orElse/orElseGet etc.

Eugene
  • 117,005
  • 15
  • 201
  • 306