On Thu, 18 Dec 2025 12:41:16 GMT, Alan Bateman <[email protected]> wrote:
>> @AlanBateman Thank you for the feedback!
>>
>> ## Analysis:
>>
>> **JEP 358 message advantages:**
>> - More detailed: Shows which method call failed ("String.length()")
>> - More informative: Explains the context of the failure
>>
>> **Objects.requireNonNull advantages:**
>> - Explicit API contract: Makes it clear at method entry that null is not
>> allowed
>> - Fail-fast: Exception occurs at method entry, not deep in the method body
>> - Consistent across JDK versions: Works the same way in JDK 8, 11, 14, 17,
>> etc.
>> - Simpler message: Just the parameter name
>>
>> I understand that with JEP 358, there's less need for explicit null checks
>> in many cases. However, I believe `Objects.requireNonNull` still provides
>> value by:
>> 1. Making the API contract explicit at the method signature level
>> 2. Failing fast before any method body execution
>> 3. Providing consistent behavior across all JDK versions
>>
>> I'm open to feedback on whether this change is appropriate, or if we should
>> rely on JEP 358's automatic messages instead. What would you recommend?
>
>> I'm open to feedback on whether this change is appropriate, or if we should
>> rely on JEP 358's automatic messages instead. What would you recommend?
>
> Would you mind pasting in the existing NPE message and the new NPE message?
Of course. Thank you for the review, @AlanBateman!
Here are the NPE messages:
**Existing NPE message (JEP 358 automatic, without Objects.requireNonNull):**
java.lang.NullPointerException: Cannot invoke "String.length()" because "s" is
null
**New NPE message (with Objects.requireNonNull):**
java.lang.NullPointerException: s
The JEP 358 message provides more context (shows which method call failed),
while Objects.requireNonNull provides a simpler message and fails fast at
method entry.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3672535570
