On Thu, 18 Dec 2025 22:46:00 GMT, Roger Riggs <[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"
>
> $0.02, The original exception message is complete and accurate without adding
> extra bytecodes or an extra line of source.
> I don't think the addition is worthwhile.
@RogerRiggs Thank you for the review!
I've reviewed the OpenJDK codebase and found that most code uses just the
parameter name (e.g., `Objects.requireNonNull(out, "out")`), which is what I've
used here.
However, the Objects.java Javadoc examples use more descriptive messages like
`"bar must not be null"`.
Using `Objects.requireNonNull` at the method entry point allows us to
immediately identify the problematic parameter and makes the API contract
explicit. By using a more descriptive message like `"s must not be null"`, we
can provide a complete and accurate error message that clearly indicates which
parameter is null and why it cannot be null, while still maintaining the
benefits of fail-fast validation at method entry.
I'm open to changing it to a more descriptive message if that's the preferred
approach.
Would you like to share your opinion on this approach?
- `Objects.requireNonNull(s, "s must not be null")`
I'm happy to follow the project's conventions and your guidance on this.
Thank you for take time to review this.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3672625364
