4
getActivity().finish();

Now editor shows warning where the method is annotated with @Nullable. Then it shows suggestion to use requireNonNull. When I accept its changes then it converts code to this, and warning is gone.

Objects.requireNonNull(getActivity()).finish();

Does it make sense to use requireNonNull?

Implementation of requireNonNull is

public static <T> T requireNonNull(T obj) {
    if (obj == null)
        throw new NullPointerException();
    return obj;
}

So my code will still crash if getActivity() is null.

We should null check for this.

if (getActivity() != null)
     getActivity().finish();

I think null check is better than requireNonNull, what you say? If yes, then editor should not suggest to use requireNonNull there.

Because it is not safe to use requireNonNull in fields having state like Activity. Am I missing some benefit of requireNonNull?

Khemraj Sharma
  • 57,232
  • 27
  • 203
  • 212

2 Answers2

3

The explicit null check is correct here, since you want to prevent a NullPointerException from being thrown if getActivity returns null.

Objects.requireNonNull() is often used for parameter validation (fail fast) and can be used for example in constructors:

/** 
 * Constructs a new Foo instance. 
 *
 * @param bar a bar, not null  
 */
public Foo(Bar bar) {
    this.bar = Objects.requireNonNull(bar);
}

Objects.requireNonNull will throw a NullPointerException (which is a RuntimeException), if the object turns out to be null. I suppose that the IDE is suggesting not the ideal solution here.

Glains
  • 2,773
  • 3
  • 16
  • 30
  • So this will create a `RuntimeException`. Okay, so IDE is not showing a good suggestion for null check, its just an implementation for `fail fast`. – Khemraj Sharma Jul 31 '18 at 09:17
2

This is explicit null check for Java objects introduced in Java 8. Objects class includes lot more similar static methods too. Refer the Java Doc Here.

But those are more usable with Java 8 lambda expressions. When we use functional operations like below example we can enforce null checks more conveniently and particularly using requireNonNull method we can easily eliminate null values.

ArrayList<Object> abc = new ArrayList<>();

Say we have 100 elements in this ArrayList and some random values are null and at the same time we need process those not null values. Then we can implement following;

abc.stream().map(Objects::requireNonNull).forEach(obj -> {
     // Whatever action to be on obj element. 
});

If you don't know lambda expression, read it here. Don't worry if you don't know Lambda expressions.

Update:

abc.stream().filter(Objects::nonNull).forEach(obj -> {
      // Whatever action to be on obj element. 
});

Above example also similar to previous one. But there are their own differences. As per the requirement we can choose whether we need to use .forEach functional operation soon after a filter or not.

Sachith Dickwella
  • 1,388
  • 2
  • 14
  • 22
  • 1
    As the docs state, `Objects::requireNonNull` "is designed primarily for doing parameter validation", `Objects::nonNull` should be preferred to filter collections using streams. If you process `null` values in the first example, a RuntimeExcpetion would be thrown, which is clearly not the desired behaviour. – Glains Jul 31 '18 at 09:08
  • Yeah. Probably the purpose of this method is not the same. Similar scenario like this, `Object obj = Objects.requireNonNull(abc, "ABC is null");` would work better. Which also occurs at the initialization. – Sachith Dickwella Jul 31 '18 at 09:24