On Wed, 17 Dec 2025 13:37:17 GMT, Alan Bateman <[email protected]> wrote:
>> ## Summary
>>
>> Add explicit null check using `Objects.requireNonNull` in
>> `DataOutputStream.writeBytes(String s)` to provide a clearer error message
>> and make the API contract explicit.
>>
>> ## Problem
>>
>> The `writeBytes` method currently throws a `NullPointerException` when
>> `null` is passed, but the error message may not be clear in all contexts.
>> While JDK 14+ provides helpful NullPointerException messages through
>> JEP 358 (Helpful NullPointerExceptions), adding an explicit null check
>> using `Objects.requireNonNull` makes the API contract more explicit and
>> provides consistent error messaging across different JDK versions.
>>
>> ## Solution
>>
>> Added `Objects.requireNonNull(s, "s")` at the beginning of the
>> `writeBytes(String s)` method. This ensures:
>> - A clear error message ("s") is provided when null is passed
>> - The API contract explicitly states that null is not allowed
>> - The method fails fast with a descriptive exception
>>
>> ## Issue
>> Fixes JDK-8373660
>>
>> **JBS Issue Link**:
>> https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373660
>>
>>
>> ## Type of Change
>> - [x] Test addition/modification
>> - [x] Bug fix
>> - [ ] New feature
>> - [ ] Documentation improvement
>> - [ ] Refactoring
>>
>> ## Testing
>>
>> A new JUnit test has been added to verify the null check behavior:
>>
>>
>> # Run the specific JUnit test file
>> make test
>> TEST="jtreg:test/jdk/java/io/DataOutputStream/DataOutputStreamTest.java"
>>
>> # Or run all tests in the DataOutputStream directory
>> make test TEST="jtreg:test/jdk/java/io/DataOutputStream"
>
>> Add explicit null check using Objects.requireNonNull in
>> DataOutputStream.writeBytes(String s) to provide a clearer error message and
>> make the API contract explicit.
>
> Can you paste in the existing NPE message vs. the new NPE message? With
> Helpful NPEs (JEP 358), there is a less need to make changes like this.
@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?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3669945336
