Skip to content

Conversation

artembilan
Copy link
Member

Fixes: #10314

Looks like a boolean return for the TcpListener.onMessage() is a leftover of some earlier design or some idea which didn't make it into the project. On the other hand, all the logic in the project around this onMessage() usage is properly handled by the delegation or exceptions.

  • Change TcpListener.onMessage() to have a void as return type
  • Fix all the respective usages and simplify some implementations with removing those bogus return false; and using proper if..else logic if necessary
  • Fix some code style in the affected classes, like proper assertThat or diamond operators

…r `void`

Fixes: spring-projects#10314

Looks like a `boolean` return for the `TcpListener.onMessage()` is a leftover
of some earlier design or some idea which didn't make it into the project.
On the other hand, all the logic in the project around this `onMessage()` usage
is properly handled by the delegation or exceptions.

* Change `TcpListener.onMessage()` to have a `void` as return type
* Fix all the respective usages and simplify some implementations with removing those bogus `return false;`
and using proper `if..else` logic if necessary
* Fix some code style in the affected classes, like proper `assertThat` or diamond operators
Copy link
Contributor

@cppwfs cppwfs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!
Just a couple of formatting nitpicks.

*/
@Nullable Message<?> getReply() {
@Nullable
Message<?> getReply() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the @Nullable move to the line above the method?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because this method does not have modifiers and annotation is treated by formatter as for the whole method.
I agree on consistency discrepancy here, but I prefer to keep formatter happy to avoid unnecessary changes in the future .

this.interceptedSenders.forEach(snder -> snder.removeDeadConnection(connection));
if (sender != null && this.interceptedSenders != null
&& !(sender instanceof TcpConnectionInterceptorSupport)) {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blank line can probably be removed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, my preference for better readability is to have a blank line after multi-line if.
Same reason as with a blank line before method body after multi-line header.

Copy link
Contributor

@cppwfs cppwfs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with your response.

Things look great!

@cppwfs cppwfs merged commit faa3eb4 into spring-projects:main Aug 15, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Revise TcpListener.onMessage() contract
2 participants