5

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

lmk
  • 654
  • 5
  • 21
  • 1
    I would assume it's because the Collection API predates Streams; also how is `Collection.stream()` inadequate? – Elliott Frisch Jul 07 '23 at 03:35
  • 1
    @ElliottFrisch Thanks, Collection API might predate Streams but that doesn't mean its static right...for example Collection interface does have `Collection#removeIf(java.util.function.Predicate)` added after 1.8 when Streams & Predicates were added. – lmk Jul 07 '23 at 04:17
  • Also its not that `Collection.stream()` is inadequate, its just that its not _required_ for this purpose. Also once we create a stream from the collection we lose out on the advantages that come with the Collection & its concrete implementations. – lmk Jul 07 '23 at 04:27

1 Answers1

10
  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.

Donald Raab
  • 6,458
  • 2
  • 36
  • 44
  • 2
    Awesome write-up in that first link. Was "Hi Don" directed at you by any chance? – shmosel Jul 07 '23 at 04:57
  • 2
    I was a member of the JSR 335 Expert Group and lambda-libs-spec-experts mail list and I had implemented my own collections via Eclipse Collections (known at the time as GS Collections). It is also possible this was a greeting to another Don. – Donald Raab Jul 07 '23 at 06:01
  • 6
    Don, I'm pretty sure the "Hi Don" in Brian's email was directed at you. :-) – Stuart Marks Jul 07 '23 at 06:05
  • 1
    @DonaldRaab Thank you so much for that link. The deliberations noted there ('bun' problem) were precisely the kind of things running in my mind that caused me to wonder if there is more here to know by asking this question (albeit not as articulately). I am super glad & thankful for your time & the information shared. 'Reducing conflict surface area' is indeed a consideration..as is the 'model confusion' aspect..thank you once again! – lmk Jul 08 '23 at 09:29
  • 1
    @DonaldRaab There is a lot shared here for me to read...thank you once again for that...i will read it in leisure tomorrow.. – lmk Jul 08 '23 at 09:34