Hello! The example you have provided is indeed a workaround. Such a setup indeed covers most of the problems, nothing I could get from the top of my head that can't be accomplished using this.
However, there are a few downsides: 1. Obvious performance and memory overhead. I think no elaboration here is needed, maybe jsut point out that, from my experience, we are talking about multiples of 10 when explaining gap in performance. 2. Extremely uncomfortable API. Most of the operations with multisets, at the end of the day, converge to iteration over elements. Every data processing pipeline requires additional flattening before processing in most of the cases, or using nested loops. If, for example, you have a web API that works with data processing and visualization, every IO operation would require mapping from list or array to map back and forth. This could (and will) introduce some errors and make code less maintainable. Also, which is important for me, this approach is very frustrating. My goal will always be developer experience improvement in the first place. I know that is not a top-level priority for Java maintainers, but I will always try my best to make the life of Java users more comfortable. вс, 21 апр. 2024 г. в 01:57, - <liangchenb...@gmail.com>: > 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.olexa...@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? >> >
