On Sun, 3 Aug 2025 13:42:41 GMT, Tagir F. Valeev <[email protected]> wrote:
>> Implementation of Comparator.min and Comparator.max methods. Preliminary >> discussion is in this thread: >> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html >> The specification is mostly composed of Math.min/max and Collections.min/max >> specifications. >> >> The methods are quite trivial, so I don't think we need more extensive >> testing (e.g., using different comparators). But if you have ideas of new >> useful tests, I'll gladly add them. >> >> I'm not sure whether we should specify exactly the behavior in case if the >> comparator returns 0. I feel that it could be a useful invariant that >> `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different >> argument, partitioning the set of {a, b} objects (even if they are equal). >> But I'm open to suggestions here. > > Tagir F. Valeev has updated the pull request incrementally with one > additional commit since the last revision: > > Add @implSpec Overall, looks good, and thanks for persevering through all the nitpicky comments. But the high quality of the result justifies the effort. A couple items of commentary, but nothing actionable. * I note that the `@param` and `@return` clauses end in periods. This isn't the typical javadoc style that I'm familiar with. However, I note that most of the rest of this file is styled this way, so the rule about conforming to the prevailing local style applies. * Although `<i>` is no longer used here, there doesn't seem to be a clear preference about the use of `<i>` vs `<em>` markup in javadoc text. In the `java.base` module the ratio is about 3,000 to 2,000 uses, respectively. The `<i>` markup has a clear but not overwhelming majority. On the other hand, this feels like a 1990s HTML argument, and maybe we just don't care. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25297#pullrequestreview-3242256168
