Add Objects.requireNonNullElse/ElseGet support to AnnotateNullableParameters

[timtebeek]

Summary

• Enhanced AnnotateNullableParameters recipe to recognize Objects.requireNonNullElse() and Objects.requireNonNullElseGet() calls as indicators of nullable parameters
• These methods provide default values when arguments are null, implying they accept nullable parameters

Why this change?

• Objects.requireNonNull() throws an exception if the argument is null, enforcing non-null parameters
• Objects.requireNonNullElse() and Objects.requireNonNullElseGet() provide default values for null arguments, indicating the parameters can be null
• Parameters that use these fallback methods should be annotated with @Nullable

Changes

• Added Objects.requireNonNullElse(..) and Objects.requireNonNullElseGet(..) to the list of null-checking method matchers
• Implemented visitMethodInvocation to handle standalone calls (not just those in if conditions)
• Added comprehensive test coverage for both methods

Test plan

• Added test for Objects.requireNonNullElse with default values
• Added test for Objects.requireNonNullElseGet with supplier functions
• Added test for multiple parameters with mixed usage of both methods
• All existing tests continue to pass

🤖 Generated with Claude Code

[timtebeek]

Not sure I agree with Claude here; when using requireNonNull I'd expect the variable to not be nullable, as we don't expect folks to rely on the NPE that gets thrown.

[timtebeek]

@stefanodallapalma this seems right up your alley ; any suggestions or concerns with this addition?

[stefanodallapalma]

Not sure I agree with Claude here; when using requireNonNull I'd expect the variable to not be nullable, as we don't expect folks to rely on the NPE that gets thrown.

@timtebeek I had a similar concern here.

Objects.requireNonNullElse() and requireNonNullElseGet make sense. Now I realized we could support Optional.ofNullable() too

[timtebeek]

Thanks yes requireNonNull is quite the opposite, but requireNonNullElse* and Optional.ofNullable do indicate nullable parameters I think, or at the very least defensive coding. From your comment it's not yet clear whether you'd agree with the changes made here for those specific methods (not including requireNonNull from an earlier iteration). Is the current diff ok to merge you think?

[stefanodallapalma]

Oh yeah, thanks. The current diff looks good to me. I only left a minor comment

[stefanodallapalma]

I find this test case a little redundant due to data != null. I'd rather test something like the following:

Optional.ofNullable(data).ifPresent(it -> ...);

What do you think?

[timtebeek]

Yes makes sense, thanks! Will merge with that change.