Search code examples
javacollectionsjava-streamjava-11

Is there a reason the Java Collection interface doesn't have direct allMatch, anyMatch & noneMatch APIs using Predicates

I am wondering if there is a reason the Java Collection interface doesn't have direct allMatch(), anyMatch() & noneMatch() APIs using Predicates similar to the ones on the Stream interface.

It seems to me that having these on the Collection interface (also) would get us much of the same advantages that we get with the other Collection interface methods (contains(), containsAll or even removeIf) besides not requiring the use of Streams to do these operations.

I was going with a thin wrapper utility for this, but wanted to hear from folks on the above..is it just a matter of priority for the OpenJDK community given the workload or are there other design considerations involved.

Thanks

Solution
    1. "Reducing conflict surface area." -Brian Goetz, September 2012, lambda-libs-spec-experts mail list.

    The more default methods that get introduced onto interfaces like Collection that have been around for more than two decades, the more likely there are to be problems caused for other third-party libraries or applications that have extended these interfaces.

    I am the creator of the Eclipse Collections library and have had to fix breaks caused three times over the years by new default methods that were added to existing interfaces, and in the case of JDK 21, new interfaces being added to the Collection hierarchy with default methods. The default methods we have collided with over the years and had to fix and release a new version of Eclipse Collections are:

    • sort - added as default method to List interface in JDK 8
    • isEmpty - added as a default method to CharSequence interface in JDK 15
    • getFirst, getLast - default methods in SequencedCollection in JDK 21 via JEP 431

    Update (July 8, 2023) - It looks like the issue we encountered in Eclipse Collections with JDK 21 SequencedCollection interface is a compilation only issue, and won't require a new release of Eclipse Collections to work with JDK 21.

    I wrote about some of these in The benefits of participating in the OpenJDK Quality Outreach Program. The method sort we were able to fix before open sourcing GS Collections, which is now Eclipse Collections. The problem sort caused was more troublesome as the method returned void. We had to rename our method to sortThis, which returns a reference to the MutableList being sorted.

    There is a great writeup by Stuart Marks which explains in detail the problem Eclipse Collections encountered when CharSequence.isEmpty was added as a default method. Reading this blog will help explain some of the challenges that can arise when adding new default methods to interfaces. These challenges also exist for any libraries that extend existing interfaces with new default methods. Great care is taken when new default methods are added to existing interfaces in the JDK. A heads up from the OpenJDK Quality Group was sent out to the community about the new default methods arriving in the new SequencedCollection interface in JDK 21.

    Note: Eclipse Collections has methods named anySatisfy, allSatisfy, noneSatisfy. There would be no compile issues in Eclipse Collections with anyMatch, allMatch, noneMatch being added to java.util.Collection as default methods. That does not mean there are no other libraries that could encounter potential issues if these methods were added.