That's cool.. but I have the same question that other, why is the reason to sort?

makes sense ty

Because now there are better alternatives: Map.of(...). But when that code was written, it wasn't a thing yet.

edit: well, at that time, computeIfAbsent would have been an option, tho, iirc.

Could you elaborate? Why shouldn't I used instance initialization blocks?

Good, but I don't know why's that considered a good practice. You should not play with IIBs of standart classes

Almost. If itemCount could be zero, then that fails. Use

return (itemCount + itemsPerPage - 1) % ItemsPerPage + 1;

I don't remember if zero is allowed in the statement, but it should just be a habit in Java, C and C++ to avoid negative arguments to %.

exelent

The best possible time complexity for this task is linear.
This implementation has linear-logarithmic time complexity and it also corrupts the initial data.
Conciseness can never justify poor performance. Sorry, but it's definitely not the best practice.

1. You are wrong - to sort primitives Java uses the so-called Dual-Pivot Quicksort. This algorithm is based on quicksort, as obvious from its name, but in fact, comprises many technics to ensure linear-logarithmic performance even with the massive data.

2. Your solution is computationally intensive as well, it performs iteration through the entire array B for every element in array A. That gives O(n * m) time complexity.
   And this task can be solved in a linear time (try to refine your algorithm, or you may look at my solution).
   Additionally, your code has a side effect - it mutates array B.

this solution returns pos=[3, 7, 10], peaks=[6, 3, 4] and not pos=[3, 7], peaks=[6, 3], for this input.

This solution gives a failure to this arr 3,2,3,6,4,1,2,3,2,1,4,3
it says it should return pos=[3, 7], peaks=[6, 3]
but this actually returns pos=[3, 7, 10], peaks=[6, 3, 4]
which I think is ture because if Iam not wrong 4 here is a peak!!