RFR: JDK-8348030 : Extend Math.min and Math.max to support multiple parameters [v2]

Aviad Zer duke at openjdk.org
Fri Feb 7 14:46:11 UTC 2025


On Mon, 20 Jan 2025 11:43:13 GMT, Aviad Zer <duke at openjdk.org> wrote:

>> This change extends the Math.min function to support multiple parameters, improving its usability and code readability.
>> 
>> Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result.
>> 
>> Benefits:
>> 
>> Simplifies code by eliminating the need for nested Math.min calls.
>> Enhances readability, especially when comparing multiple values.
>> Offers consistency with existing Math.min usage patterns.
>
> Aviad Zer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Math.java by adding extended max function

Can you please keep the PR? I'm still working on it

בתאריך יום ו׳, 7 בפבר׳ 2025, 15:16, מאת Per-Ake Minborg ‏<
***@***.***>:

> Thanks for socializing your idea @aviad1486 <https://github.com/aviad1486>
> !
>
> I think we should *not* integrate this PR and there are many reasons for
> that including, but not limited to:
>
>    - There are easy ways to provide this kind of functionality outside
>    the JDK.
>    - We are not sure there is a need for this in the community.
>    - Adding these overloads means we commit to supporting them in
>    perpetuity.
>    - There are works ongoing to intensify Math::min and Math::max. This
>    means we'd have to do the same here.
>    - There are replacements for many similar constructs (e.g. using a
>    reduction of streams).
>    - The reviewing capacity is limited and currently, we are focusing on
>    major additions to the Java platforms (e.g. Valhalla).
>    - It is not clear which other methods in Math (and MathExact) should
>    be expanded in a similar way.
>    - It is not clear what performance, escape analysis, and inline
>    factors this would impact.
>
> Languages such as Haskel support "infix" operators meaning you could write
> something like a 'min' b 'min' c. If such a feature would be available in
> Java in the distant future, then the use of the proposed methods would be
> reduced but we would still have to maintain them forever.
>
> So, I strongly suggest that we should close this PR without integrating
> it. Thanks again @aviad1486 <https://github.com/aviad1486> for your
> effort.
>
>> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/23138#issuecomment-2642878666>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/BEHBFNK742B4HJSYSAB4YQL2OSW2ZAVCNFSM6AAAAABVHL4VJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBSHA3TQNRWGY>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2643132031


More information about the core-libs-dev mailing list