Skip to content

Conversation

@artembilan
Copy link
Member

To avoid resizing at runtime, it is better to use ArrayList with a predefined size. In some cases it is possible from the context of the list we are creating

  • Fix typos in Javadocs of the affected classes according to IDE suggestions
  • Use diamond operators for modern Java in the affected classes
  • pattern matching expressions for if where IDE suggested
  • Use switch in one place instead of if..else. Again: good suggestion from IDE
  • Fix Nullability for the router hierarchy
  • Have to add "redundant" cast in the XPathRouter to make NullAway happy

To avoid resizing at runtime, it is better to use `ArrayList` with a predefined size.
In some cases it is possible from the context of the list we are creating

* Fix typos in Javadocs of the affected classes according to IDE suggestions
* Use diamond operators for modern Java in the affected classes
* pattern matching expressions for `if` where IDE suggested
* Use `switch` in one place instead of `if..else`. Again: good suggestion from IDE
* Fix Nullability for the router hierarchy
* Have to add "redundant" cast in the `XPathRouter` to make NullAway happy
@artembilan artembilan added this to the 7.0.0 milestone Nov 13, 2025
@artembilan artembilan requested a review from cppwfs November 13, 2025 23:24
@artembilan
Copy link
Member Author

Let me know if this disturbanly long for review!
Thanks

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.

Fantastic!
Thank you for doing this.

Just some nitpicks.


private List<HandlerMethodArgumentResolver> buildArgumentResolvers(boolean listCapable) {
List<HandlerMethodArgumentResolver> resolvers = new ArrayList<>();
List<HandlerMethodArgumentResolver> resolvers = new ArrayList<>(6);
Copy link
Contributor

Choose a reason for hiding this comment

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

I know this is being a bit picky but I think a constant would be better here than the number 6.

if (incomingCorrelationId != null) {
if (incomingSequenceDetails == null) {
incomingSequenceDetails = new ArrayList<>();
incomingSequenceDetails = new ArrayList<>(1);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use a constant here?

validate();

final List<FileListFilter<File>> filtersNeeded = new ArrayList<>();
final List<FileListFilter<File>> filtersNeeded = new ArrayList<>(3);
Copy link
Contributor

Choose a reason for hiding this comment

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

here as well :-)

public abstract class HttpRequestHandlingEndpointSupport extends BaseHttpInboundEndpoint {

private final List<HttpMessageConverter<?>> defaultMessageConverters = new ArrayList<>();
private final List<HttpMessageConverter<?>> defaultMessageConverters = new ArrayList<>(10);
Copy link
Contributor

Choose a reason for hiding this comment

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

ditto

public void afterPropertiesSet() {
List<Object> converters = new ArrayList<>();
List<Object> converters =
new ArrayList<>(7 + (this.customConverters != null ? this.customConverters.length : 0));
Copy link
Contributor

Choose a reason for hiding this comment

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

Use constant instead of 7.
I know Picky picky :-)

@artembilan
Copy link
Member Author

Any reasons asking for those constants?
Logically they don’t make sense because most of those lists are local variable. And technically they won’t make difference at runtime.

@cppwfs
Copy link
Contributor

cppwfs commented Nov 14, 2025

Why 6? I read the code and I understand why. But is there a constant we could use to add clarity?

@artembilan
Copy link
Member Author

Again: those lists are local variables.
The top level contract would make it more confusing.
If I feel a bit lost understanding the reason behind constant on the matter, then other code readers may suffer as well.
There are a lot of similar new ArrayList(number) in SF, and looks like no one complains.

Sorry, to say that but I wish you just bite this bullet and let the "magic number" a shot!
We may come back to constant subject when we got some real problem from community.

Any other reasons not just clarity?

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

Thank you for the optimizations. This is great!

@cppwfs cppwfs merged commit bcca956 into spring-projects:main Nov 14, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants