RFR: 8329760: Add indexOf(Predicate<? super E> filter) to java..util.List interface

[Evemose]

On Fri, 5 Apr 2024 00:00:58 GMT, Evemose <duke at openjdk.org> wrote:

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

currently awaiting for initial issue triage to complete

side note: looks like this code have been reformated and some unused imports has been reformated. jdk compiles and works just fine, so i guess its not a big deal

> Won't this make some calls ambiguous? For example, passing `null`:
> 
> ```java
> List<String> l;
> l.indexOf(""); // Fine
> l.indexOf(null); // Now fails to compile
> ```
> 
> Edit: I'm not a reviewer, but I decided to point this out.

I`ve tested it. Now calling indexOf with null as literal calls indexOf(Predicate) instead, as Predicate is lower in class hierarchy than Object (ofc it does not apply to varibles that store null, those works just as usual)

If you want to call indexOf(Object) instead, you will have to cast null to desired type manually

> ```java
> List<String> l;
> l.indexOf(""); // Fine
> l.indexOf((String)null); // Will invoke indexOf(Object)
> ```

Question to reviewers: what do you think would be the best way to handle issue discussed above?

PS: converted PR to draft untill the issue is resolved

PPS: The idea I came up with is to possibly rename indexOf(Predicate) to something like findIndex(Predicate) or indexOfMatching(Predicate) as a way to both avoid unexpected behaviour and preserve source compatibility

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2038490998
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2038506989
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2045522079
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046196342