Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8175760 | 10 | Volker Simonis | P3 | Resolved | Fixed | b02 |
- Objects.requireNonNull(T, Supplier) does not check for the Supplier
argument being null. Instead it relies on the fact, that the VM will
implicitly throw a NullPointerException when it calls .get on the
Supplier argument during the creation of the explicit
NullPointerException which it is supposed to throw.
- this behavior slightly differs from Objects.requireNonNull(T,
String) which simply creates a NullPointerException with a null
message in the case where the String argument is null.
- the difference is not evident in the OpenJDK, because the HotSpot VM
creates a NPE with a null message by default if we call a method on a
null object.
- however creating such a NPE with a null message when invoking a
method on a null object is not enforced by the standard, and other
implementations can do better :) For the following trivial program:
public class NonNull {
public static void main(String[] args) {
Supplier<String> ss = null;
Object o = Objects.requireNonNull(null, ss);
}
}
the current OpenJDK implementation returns:
Exception in thread "main" java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:290)
at NonNull.main(NonNull.java:8)
but the SAP JVM will print:
Exception in thread "main" java.lang.NullPointerException: while
trying to invoke the method java.util.function.Supplier.get() of a
null object loaded from local variable 'messageSupplier'
at java.util.Objects.requireNonNull(Objects.java:290)
at NonNull.main(NonNull.java:8)
which is at least confusing for a call to Objects.requireNonNul() with
a null Supplier. We think the exception should be the same like the
one we get when invoking Objects.requireNonNul() with a null String.
- because of this difference (and because we like our extended
Exception messages :) the JCK test for Objects.requireNonNul(T,
Supplier) (i.e.
api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
removed from TCK 8 and is still commented out in TCK 9
(npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).
I really think that the simplest and most natural fix for this problem
is to simply check for a null Supplier argument and create the NPE
with an explicit null message in that case (as outlined in the
webrev). This:
- makes the two requireNonNul() overloads for String and Supplier
behave the same (which I think was the initial intention).
- doesn't require documentation changes
- makes it possible to write a simple and conforming TCK test
argument being null. Instead it relies on the fact, that the VM will
implicitly throw a NullPointerException when it calls .get on the
Supplier argument during the creation of the explicit
NullPointerException which it is supposed to throw.
- this behavior slightly differs from Objects.requireNonNull(T,
String) which simply creates a NullPointerException with a null
message in the case where the String argument is null.
- the difference is not evident in the OpenJDK, because the HotSpot VM
creates a NPE with a null message by default if we call a method on a
null object.
- however creating such a NPE with a null message when invoking a
method on a null object is not enforced by the standard, and other
implementations can do better :) For the following trivial program:
public class NonNull {
public static void main(String[] args) {
Supplier<String> ss = null;
Object o = Objects.requireNonNull(null, ss);
}
}
the current OpenJDK implementation returns:
Exception in thread "main" java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:290)
at NonNull.main(NonNull.java:8)
but the SAP JVM will print:
Exception in thread "main" java.lang.NullPointerException: while
trying to invoke the method java.util.function.Supplier.get() of a
null object loaded from local variable 'messageSupplier'
at java.util.Objects.requireNonNull(Objects.java:290)
at NonNull.main(NonNull.java:8)
which is at least confusing for a call to Objects.requireNonNul() with
a null Supplier. We think the exception should be the same like the
one we get when invoking Objects.requireNonNul() with a null String.
- because of this difference (and because we like our extended
Exception messages :) the JCK test for Objects.requireNonNul(T,
Supplier) (i.e.
api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
removed from TCK 8 and is still commented out in TCK 9
(npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).
I really think that the simplest and most natural fix for this problem
is to simply check for a null Supplier argument and create the NPE
with an explicit null message in that case (as outlined in the
webrev). This:
- makes the two requireNonNul() overloads for String and Supplier
behave the same (which I think was the initial intention).
- doesn't require documentation changes
- makes it possible to write a simple and conforming TCK test
- backported by
-
JDK-8175760 Gracefully handle null Supplier in Objects.requireNonNull
-
- Resolved
-
- relates to
-
JDK-8033909 Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself
-
- Closed
-