On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang <[email protected]> wrote:

>> Provide a general facility for our null check APIs like 
>> Objects::requireNonNull or future Checks::nullCheck (void), converting the 
>> existing infrastructure to start tracking from a given stack site (depth 
>> offset) and a given stack slot (offset value).
>> 
>> This is a necessary prerequisite for 
>> https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null 
>> messages to `Objects::requireNonNull`.
>
> Chen Liang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update NPE per roger review

Hello Chen, I had a look at the changes, but I'm missing some broader context 
of this change.

The JBS issue and the PR description states that this PR is in preparation (to 
upcoming additional work?) to support better `NullPointerException` exception 
messages when some code uses `Objects.requireNonNull()`. It also talks about a 
`java.lang.runtime.Checks::nullCheck` method, but there's no such 
`java.lang.runtime.Checks` class in mainline and it appears to be a proposed 
class in Valhalla project (https://bugs.openjdk.org/browse/JDK-8357936). But 
there too it's non-existent for now. So I'll leave out the `Checks` class from 
this discussion.

If this change were to be integrated into mainline, would there be any change 
to NullPointerException exception messages in any code paths? If not, then 
would it better to do these changes along with the `Objects.requireNonNull()` 
change itself, as part of https://bugs.openjdk.org/browse/JDK-8233268? In 
JDK-8233268, there's also a comment from Goetz proposing how the new exception 
message should look like. If the current changes were to be done, would it 
allow for that proposal to be implemented?

I did have a brief look at the new jtreg test cases in this PR, but it wasn't 
immediately clear to me which APIs would start seeing this new proposed 
exception messages.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3284904586

Reply via email to