RFR: 8317993: Add capturing factories to classes in java.util.function package [v5]

[Per Minborg]

On Wed, 18 Oct 2023 09:00:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
>> 
>> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
>> 
>> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
>> 
>> 
>> // Resolve ambiguity
>> var function = Function.of(String::isEmpty); // Function<String, Boolean>
>> var predicate = Predicate.of(String::isEmpty); // Predicate<String>
>> 
>> // Fluent composition
>> var chained = Function.of(String::length)       // Function<String, Integer>
>>                    .andThen(Integer::byteValue);      // Function<String, Byte>
>> 
>> 
>> Please see the original bug report for a comprehensive description of these proposed changes.
>> 
>> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
>> 
>> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pretty

As much as I liked this idea from the beginning, I am getting increasingly skeptical. By introducing methods like these, we risk code compatibility over time and this feature would instead turn into a straight jacket. The objectives of this PR can be reached by language changes rather than the library approach attempted here. It would, for example, be possible to consider adding diamond operator/type inference in casts. So rather than `Function.of(String::isEmpty) `, one might write `(Function<>)String::isEmpty` which will be inferred to `(Function<String, Boolean>)String::isEmpty`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16213#issuecomment-1770157285