Bag (Multiset) Collection

[-]

Hi IP-24 Oleksandr Rotan',
You can use a Map<T, Collection<T>>. This map stores T as the object
equivalence key, and each Collection<T> in this map stores the values known
to be equal to the key. Since map compares keys by equals, any key in the
collection can be used to find the collection in the Map<T, Collection<T>>.

If you want a Tree/Navigable multiset, you can just make it a
NavigableMap<T, Collection<T>>. If you use this concurrently, you can
replace the value Collection<T> with something like CopyOnWriteArrayList<T>.

Is there any Multiset functionality not covered by such a Map<T,
Collection<T>> setup?

P.S. For the other versions of tree collections, I think JDK uses Red Black
tree due to its superior performance when there's frequent removal. AVL is
known for faster additions but involves a lot more balance operations
during removal. If we are looking at immutable navigable/sorted
collections, we can use an array and perform binary search, which works
just like a tree.

Regards,
Chen Liang


On Sat, Apr 20, 2024 at 3:25 PM ІП-24 Олександр Ротань <
rotan.olexandr at gmail.com> wrote:

> In this letter I would like to express some of my thoughts regarding the
> potential Multiset interface.
>
> I, personally, have encountered a few situations where such an interface
> could come in handy, mostly when I needed an ordered collection that
> permits duplicates. That time I used guava`s TreeMultiset, but I think Java
> itself should have such a collection in its std library. While it is not a
> very common problem, there are still a bunch of use cases where such things
> could come in handy.
>
> I am willing to take on development of such thing, but there are a few
> concerns about Multiset:
>
> 1. Is there any other use for this besides ordered collection that permits
> duplicates? I can't remember anything else from the top of my head.
>
> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet class
> hierarchy, while not being directly connected. I think introducing any
> other ordered collection will require some refactoring of existing
> collection interfaces (for example extract SortedCollection from SortedSet,
> Navigable Collection from NavigableSet etc.). From the perspective of clean
> code, this would be the right decision, but I feel like this will be a very
> complex task to accomplish.
>
> 3. Maybe there should be few versions of Tree collection (for example, for
> regular tasks red-black tree and B-Tree for large amounts of data). I have
> some expirience implementing both, but is it really needed in standard
> library?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/e959ab8f/attachment.htm>