I won't stop you, but remember, you are not the one maintaining the large number of collection implementations in the JDK. The ones who are may feel differently. This FAQ gives a good hint of their opinion, even to your retorts.
On Sat, Apr 20, 2024, 4:44 PM ІП-24 Олександр Ротань < rotan.olexa...@gmail.com> wrote: > I agree with the point made in the FAQ about the popularity of such > problems. That said, I don't think that it is that unpopular to be ignored. > > Regarding Map.values(), this is the case, but, In my experience, one of > the main advantages of using TreeMultiset was O(long n) modification > complexity. Collection views returned by map, for obvious reasons, forbid > modification. Also, correct me if I`m wrong, but while TreeMultiset is an > unpopular requirement, it is at least as popular as TreeSet. > > Also, I may not have a full view of how such Bag collections can be > implemented and used, however, I feel like there could be more to it. > > I am not insisting on anything, I just feel that if there is someone (like > me lol) who is willing to take on full development and integration cycle, > there aren't much reason to reject such enhancements. > > сб, 20 апр. 2024 г. в 23:43, ІП-24 Олександр Ротань < > rotan.olexa...@gmail.com>: > >> I agree with the point made in the FAQ about the popularity of such >> problems. That said, I don't think that it is that unpopular to be ignored. >> >> Regarding Map.values(), this is the case, but, In my experience, one of >> the main advantages of using TreeMultiset was O(long n) modification >> complexity. Collection views returned by map, for obvious reasons, forbid >> modification. Also, correct me if I`m wrong, but while TreeMultiset is an >> unpopular requirement, it is at least as popular as TreeSet. >> >> Also, I may not have a full view of how such Bag collections can be >> implemented and used, however, I feel like there could be more to it. >> >> I am not insisting on anything, I just feel that if there is someone >> (like me lol) who is willing to take on full development and integration >> cycle, there aren't much reason to reject such enhancements. >> >> сб, 20 апр. 2024 г. в 23:31, David Alayachew <davidalayac...@gmail.com>: >> >>> Your Bag suggestion has been asked so frequently that there is an FAQ >>> entry in the official Java Docs. >>> >>> >>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a3 >>> >>> On Sat, Apr 20, 2024 at 4: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? >>>> >>>
