Re: [Collections] Potential inverse method for multimaps
On Mon, Dec 15, 2025 at 7:15 PM sebb wrote:
>
> On Sun, 14 Dec 2025 at 14:06, Gary Gregory wrote:
> >
> > On Fri, Dec 12, 2025 at 7:17 AM Paul King wrote:
> > >
> > > Okay, there doesn't seem to be a lot of interest, but I went ahead and
> > > created the PR anyway:
> > >
> > > https://github.com/apache/commons-collections/pull/665
> > >
> > > If the decision is to close the PR, at least future users wanting such
> > > functionality might find the discussion and find something useful in
> > > the PR for their own codebases.
> >
> > Hi All:
> >
> > The feature request and PR look good (after review) and fit in this
> > component's scope IMO.
> >
> > I plan on merging it unless there are valid technical objections.
>
> My concern is that this offers very little gain for a the extra
> maintenance needed.
Well, that is the PMC's call of course.
> Also, there are lots of other similar methods in 3rd party libraries
> such as Eclipse Collections.
> We don't have the resources to emulate them, nor should we do so.
Eclipse Collections is feature rich and it would be significant work
to emulate all of its features. I agree that isn't the right direction
for Commons Collections right now. I'll explain below where my
thinking came from for suggesting the "inverted" functionality.
> Given that it is not diifficult for users to create their own
> inverses, I am not convinced we should include it.
>
> I think we should only consider new features which are genuinely
> useful AND are not trivial for end users to implement correctly.
I recently did Groovy equivalents of all the examples in the book
Eclipse Collections Categorically[1]. I used JDK collections but was
also, out of interest, doing some Commons Collection and Guava
versions of some of the examples. My goal was to look for any missing
features in Groovy's collection handling methods with a similar
sentiment, i.e. looking for genuinely useful features that weren't
trivial to implement using Groovy's other features. Out of that
activity, Groovy added a groupByMany method. It was the only EC
feature, called groupByEach in its API, that couldn't easily be
implemented using existing Groovy features. Many Groovy applications
have collections of domain objects and groupByMany lets you use simple
predicates or method references for the kind of queries that would be
easy if you were using SQL but turn out to be cumbersome and
error-prone if doing long-hand. Multimaps are a good representation of
one-to-many relationships and such relationships are common. As it
turns out, the degenerative form of groupByMany/Each is invert/flip,
so it made sense for Groovy to also include that functionality, though
we retain the name groupByMany.
As part of all of that, my assessment of Commons Collections was that
grouping was a weak point compared with EC. With streams, most of the
grouping can be accommodated only slightly more verbosely, but the
groupByMany functionality isn't nice to implement using streams.
Rather than propose an equivalent to groupByMany, I thought just to
propose the degenerative form "inverted". If there was interest and
use of that, it might be worth considering the more elaborate case.
This is an example of Groovy's equivalent of "inverted" but just using
JDK vanilla collections (a by-hand multimap if you will):
//
var citiesLived = [
Alice: ['NY', 'LA'],
Bob: ['NY'],
Cara: ['LA', 'CHI']
]
var grouped = citiesLived.groupByMany() // equivalent to "inverted"
assert grouped == [
NY : ['Alice', 'Bob'],
LA : ['Alice', 'Cara'],
CHI : ['Cara']
]
//
Here is an example of the more general form:
//
record Person(String name, List cities) { }
var people = [
new Person('Alice', ['NY', 'LA']),
new Person('Bob', ['NY']),
new Person('Cara', ['LA', 'CHI'])
]
var grouped = people.groupByMany(Person::name, Person::cities)
assert grouped == [
NY : ['Alice', 'Bob'],
LA : ['Alice', 'Cara'],
CHI : ['Cara']
]
//
For Groovy, there are tens (or hundreds) of thousands of Grails
applications that use domain objects and need to do query-like
operations on such collections. I don't really know whether folks use
ORMs in combination with Commons Collections, but if that did seem
useful, it wouldn't be as trivial to implement as the degenerate
inverted form.
Cheers, Paul.
[1]
https://www.amazon.com/Eclipse-Collections-Categorically-Level-programming/dp/B0DZVK69D3
> > Gary
> >
> > >
> > > Cheers, Paul.
> > >
> > > On Fri, Dec 12, 2025 at 8:54 PM Paul King
> > > wrote:
> > > >
> > > > On Fri, Dec 12, 2025 at 8:39 PM sebb wrote:
> > > > >
> > > > > On Thu, 11 Dec 2025 at 23:49, Paul King
> > > > > wrote:
> > > > > >
> > > > > > True, I guess an analysis of the above suggested searches could
> > > > > > reveal, in some cases, the sizes of the data and why the dozens or
> > > > > > hundreds of cases mentioned above chose to use the flip/inver**
> > > > > > methods instead of double
Re: [Collections] Potential inverse method for multimaps
On Sun, 14 Dec 2025 at 14:06, Gary Gregory wrote: > > On Fri, Dec 12, 2025 at 7:17 AM Paul King wrote: > > > > Okay, there doesn't seem to be a lot of interest, but I went ahead and > > created the PR anyway: > > > > https://github.com/apache/commons-collections/pull/665 > > > > If the decision is to close the PR, at least future users wanting such > > functionality might find the discussion and find something useful in > > the PR for their own codebases. > > Hi All: > > The feature request and PR look good (after review) and fit in this > component's scope IMO. > > I plan on merging it unless there are valid technical objections. My concern is that this offers very little gain for a the extra maintenance needed. Also, there are lots of other similar methods in 3rd party libraries such as Eclipse Collections. We don't have the resources to emulate them, nor should we do so. Given that it is not diifficult for users to create their own inverses, I am not convinced we should include it. I think we should only consider new features which are genuinely useful AND are not trivial for end users to implement correctly. > Gary > > > > > Cheers, Paul. > > > > On Fri, Dec 12, 2025 at 8:54 PM Paul King wrote: > > > > > > On Fri, Dec 12, 2025 at 8:39 PM sebb wrote: > > > > > > > > On Thu, 11 Dec 2025 at 23:49, Paul King > > > > wrote: > > > > > > > > > > True, I guess an analysis of the above suggested searches could > > > > > reveal, in some cases, the sizes of the data and why the dozens or > > > > > hundreds of cases mentioned above chose to use the flip/inver** > > > > > methods instead of double storing the datasets. I would think small > > > > > immutable datasets could be suitable for double storing. For large > > > > > datasets, the storage requirements might be problematic. For mutable > > > > > sets, the double manipulations for a putAll (as one example) can > > > > > become messy. > > > > > > > > AFAICT, Eclipse Collections flip creates a new Map with the keys and > > > > values reversed. > > > > So no saving in storage. > > > > > > Certainly that would be true for cases where both the normal and the > > > inverse maps were always both needed and were created and used in a > > > short time span. In the scenarios I am using multimaps, the normal > > > data is more long-lived, and the inverse is only needed occasionally > > > when the user asks for certain "query" operations. > > > > > > > > Cheers, Paul. > > > > > > > > > > On Fri, Dec 12, 2025 at 8:19 AM sebb wrote: > > > > > > > > > > > > On Thu, 11 Dec 2025 at 20:57, Paul King > > > > > > wrote: > > > > > > > > > > > > > > Well, I can just give you one user (multiple instances in the > > > > > > > codebase) that I know of which is why I brought it up. I don't > > > > > > > know > > > > > > > anyone else using Commons Collections in their projects. Many > > > > > > > projects > > > > > > > I am involved in use Groovy which has some nicer workarounds than > > > > > > > the > > > > > > > stream variant I mentioned earlier. So, it's less critical for > > > > > > > me, but > > > > > > > I thought Java users would appreciate the simpler form. > > > > > > > > > > > > > > Asking ChatGPT about Eclipse Collections flip() usage and > > > > > > > inverse() > > > > > > > and invertFrom() for Guava points to Minecraft and Eclipse Xtext > > > > > > > as > > > > > > > quick examples of usage. It goes on to say: > > > > > > > > > > > > > > > How to find more examples yourself > > > > > > > > > > > > > > > > Use GitHub code search (or grep over downloaded repos) with > > > > > > > > queries like: > > > > > > > > > > > > > > > > Multimaps.invertFrom( > > > > > > > > invertFrom( + Multimap > > > > > > > > flip() + org.eclipse.collections (or search for Multimap.flip()) > > > > > > > > > > > > > > > > Those queries will turn up dozens — often hundreds — of usages > > > > > > > > across OSS. > > > > > > > > > > > > > > > > > > > However, if you know that you will need the inverse, it's not > > > > > > difficult to build that in parallel. > > > > > > > > > > > > Are there any occasions where the inverse has to be built later from > > > > > > an existing Multimap? > > > > > > > > > > > > > Cheers, Paul. > > > > > > > > > > > > > > > > > > > > > On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold > > > > > > > wrote: > > > > > > > > > > > > > > > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hello. > > > > > > > > > > > > > > > > > Isn't it a "chicken-and-egg" question? > > > > > > > > > Isn't the purpose of a "common" library to implement > > > > > > > > > well-defined and > > > > > > > > > generally useful functionality, in the hope that it'll incite > > > > > > > > > code reuse? > > > > > > > > > Until said functionality is implemented, it obviously cannot > > > > > > > > > be used... > > > > > > > > > > > > > > > > No, it isn't. The use case comes first. If you can point to > > > > >
Re: [Collections] Potential inverse method for multimaps
On Fri, Dec 12, 2025 at 7:17 AM Paul King wrote: > > Okay, there doesn't seem to be a lot of interest, but I went ahead and > created the PR anyway: > > https://github.com/apache/commons-collections/pull/665 > > If the decision is to close the PR, at least future users wanting such > functionality might find the discussion and find something useful in > the PR for their own codebases. Hi All: The feature request and PR look good (after review) and fit in this component's scope IMO. I plan on merging it unless there are valid technical objections. Gary > > Cheers, Paul. > > On Fri, Dec 12, 2025 at 8:54 PM Paul King wrote: > > > > On Fri, Dec 12, 2025 at 8:39 PM sebb wrote: > > > > > > On Thu, 11 Dec 2025 at 23:49, Paul King wrote: > > > > > > > > True, I guess an analysis of the above suggested searches could > > > > reveal, in some cases, the sizes of the data and why the dozens or > > > > hundreds of cases mentioned above chose to use the flip/inver** > > > > methods instead of double storing the datasets. I would think small > > > > immutable datasets could be suitable for double storing. For large > > > > datasets, the storage requirements might be problematic. For mutable > > > > sets, the double manipulations for a putAll (as one example) can > > > > become messy. > > > > > > AFAICT, Eclipse Collections flip creates a new Map with the keys and > > > values reversed. > > > So no saving in storage. > > > > Certainly that would be true for cases where both the normal and the > > inverse maps were always both needed and were created and used in a > > short time span. In the scenarios I am using multimaps, the normal > > data is more long-lived, and the inverse is only needed occasionally > > when the user asks for certain "query" operations. > > > > > > Cheers, Paul. > > > > > > > > On Fri, Dec 12, 2025 at 8:19 AM sebb wrote: > > > > > > > > > > On Thu, 11 Dec 2025 at 20:57, Paul King > > > > > wrote: > > > > > > > > > > > > Well, I can just give you one user (multiple instances in the > > > > > > codebase) that I know of which is why I brought it up. I don't know > > > > > > anyone else using Commons Collections in their projects. Many > > > > > > projects > > > > > > I am involved in use Groovy which has some nicer workarounds than > > > > > > the > > > > > > stream variant I mentioned earlier. So, it's less critical for me, > > > > > > but > > > > > > I thought Java users would appreciate the simpler form. > > > > > > > > > > > > Asking ChatGPT about Eclipse Collections flip() usage and inverse() > > > > > > and invertFrom() for Guava points to Minecraft and Eclipse Xtext as > > > > > > quick examples of usage. It goes on to say: > > > > > > > > > > > > > How to find more examples yourself > > > > > > > > > > > > > > Use GitHub code search (or grep over downloaded repos) with > > > > > > > queries like: > > > > > > > > > > > > > > Multimaps.invertFrom( > > > > > > > invertFrom( + Multimap > > > > > > > flip() + org.eclipse.collections (or search for Multimap.flip()) > > > > > > > > > > > > > > Those queries will turn up dozens — often hundreds — of usages > > > > > > > across OSS. > > > > > > > > > > > > > > > > However, if you know that you will need the inverse, it's not > > > > > difficult to build that in parallel. > > > > > > > > > > Are there any occasions where the inverse has to be built later from > > > > > an existing Multimap? > > > > > > > > > > > Cheers, Paul. > > > > > > > > > > > > > > > > > > On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold > > > > > > wrote: > > > > > > > > > > > > > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski > > > > > > > wrote: > > > > > > > > > > > > > > > > Hello. > > > > > > > > > > > > > > > Isn't it a "chicken-and-egg" question? > > > > > > > > Isn't the purpose of a "common" library to implement > > > > > > > > well-defined and > > > > > > > > generally useful functionality, in the hope that it'll incite > > > > > > > > code reuse? > > > > > > > > Until said functionality is implemented, it obviously cannot be > > > > > > > > used... > > > > > > > > > > > > > > No, it isn't. The use case comes first. If you can point to three > > > > > > > existing projects that have had to implement this functionality > > > > > > > already, and that would be willing to replace their existing code > > > > > > > with > > > > > > > a common library, then you have a case for implementing it here. > > > > > > > Absent that, it is unlikely it will be adopted broadly enough to > > > > > > > be > > > > > > > worth the effort. > > > > > > > > > > > > > > -- > > > > > > > Elliotte Rusty Harold > > > > > > > [email protected] > > > > > > > > > > > > > > - > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > --
Re: [Collections] Potential inverse method for multimaps
On Fri, Dec 12, 2025 at 10:42 PM sebb wrote: > > On Fri, 12 Dec 2025 at 10:54, Paul King wrote: > > > > On Fri, Dec 12, 2025 at 8:39 PM sebb wrote: > > > > > > On Thu, 11 Dec 2025 at 23:49, Paul King wrote: > > > > > > > > True, I guess an analysis of the above suggested searches could > > > > reveal, in some cases, the sizes of the data and why the dozens or > > > > hundreds of cases mentioned above chose to use the flip/inver** > > > > methods instead of double storing the datasets. I would think small > > > > immutable datasets could be suitable for double storing. For large > > > > datasets, the storage requirements might be problematic. For mutable > > > > sets, the double manipulations for a putAll (as one example) can > > > > become messy. > > > > > > AFAICT, Eclipse Collections flip creates a new Map with the keys and > > > values reversed. > > > So no saving in storage. > > > > Certainly that would be true for cases where both the normal and the > > inverse maps were always both needed and were created and used in a > > short time span. In the scenarios I am using multimaps, the normal > > data is more long-lived, and the inverse is only needed occasionally > > when the user asks for certain "query" operations. > > So is the inverse map dropped after each occasion? > Unless there are several queries done each time, it might well be > quicker to scan the original looking for value matches. > (Creating the inverse involves a scan) In my case, the inverse map is dropped once some output is displayed. > > > > Cheers, Paul. > > > > > > > > On Fri, Dec 12, 2025 at 8:19 AM sebb wrote: > > > > > > > > > > On Thu, 11 Dec 2025 at 20:57, Paul King > > > > > wrote: > > > > > > > > > > > > Well, I can just give you one user (multiple instances in the > > > > > > codebase) that I know of which is why I brought it up. I don't know > > > > > > anyone else using Commons Collections in their projects. Many > > > > > > projects > > > > > > I am involved in use Groovy which has some nicer workarounds than > > > > > > the > > > > > > stream variant I mentioned earlier. So, it's less critical for me, > > > > > > but > > > > > > I thought Java users would appreciate the simpler form. > > > > > > > > > > > > Asking ChatGPT about Eclipse Collections flip() usage and inverse() > > > > > > and invertFrom() for Guava points to Minecraft and Eclipse Xtext as > > > > > > quick examples of usage. It goes on to say: > > > > > > > > > > > > > How to find more examples yourself > > > > > > > > > > > > > > Use GitHub code search (or grep over downloaded repos) with > > > > > > > queries like: > > > > > > > > > > > > > > Multimaps.invertFrom( > > > > > > > invertFrom( + Multimap > > > > > > > flip() + org.eclipse.collections (or search for Multimap.flip()) > > > > > > > > > > > > > > Those queries will turn up dozens — often hundreds — of usages > > > > > > > across OSS. > > > > > > > > > > > > > > > > However, if you know that you will need the inverse, it's not > > > > > difficult to build that in parallel. > > > > > > > > > > Are there any occasions where the inverse has to be built later from > > > > > an existing Multimap? > > > > > > > > > > > Cheers, Paul. > > > > > > > > > > > > > > > > > > On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold > > > > > > wrote: > > > > > > > > > > > > > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski > > > > > > > wrote: > > > > > > > > > > > > > > > > Hello. > > > > > > > > > > > > > > > Isn't it a "chicken-and-egg" question? > > > > > > > > Isn't the purpose of a "common" library to implement > > > > > > > > well-defined and > > > > > > > > generally useful functionality, in the hope that it'll incite > > > > > > > > code reuse? > > > > > > > > Until said functionality is implemented, it obviously cannot be > > > > > > > > used... > > > > > > > > > > > > > > No, it isn't. The use case comes first. If you can point to three > > > > > > > existing projects that have had to implement this functionality > > > > > > > already, and that would be willing to replace their existing code > > > > > > > with > > > > > > > a common library, then you have a case for implementing it here. > > > > > > > Absent that, it is unlikely it will be adopted broadly enough to > > > > > > > be > > > > > > > worth the effort. > > > > > > > > > > > > > > -- > > > > > > > Elliotte Rusty Harold > > > > > > > [email protected] > > > > > > > > > > > > > > - > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > >
Re: [Collections] Potential inverse method for multimaps
On Fri, 12 Dec 2025 at 10:54, Paul King wrote: > > On Fri, Dec 12, 2025 at 8:39 PM sebb wrote: > > > > On Thu, 11 Dec 2025 at 23:49, Paul King wrote: > > > > > > True, I guess an analysis of the above suggested searches could > > > reveal, in some cases, the sizes of the data and why the dozens or > > > hundreds of cases mentioned above chose to use the flip/inver** > > > methods instead of double storing the datasets. I would think small > > > immutable datasets could be suitable for double storing. For large > > > datasets, the storage requirements might be problematic. For mutable > > > sets, the double manipulations for a putAll (as one example) can > > > become messy. > > > > AFAICT, Eclipse Collections flip creates a new Map with the keys and > > values reversed. > > So no saving in storage. > > Certainly that would be true for cases where both the normal and the > inverse maps were always both needed and were created and used in a > short time span. In the scenarios I am using multimaps, the normal > data is more long-lived, and the inverse is only needed occasionally > when the user asks for certain "query" operations. So is the inverse map dropped after each occasion? Unless there are several queries done each time, it might well be quicker to scan the original looking for value matches. (Creating the inverse involves a scan) > > > Cheers, Paul. > > > > > > On Fri, Dec 12, 2025 at 8:19 AM sebb wrote: > > > > > > > > On Thu, 11 Dec 2025 at 20:57, Paul King > > > > wrote: > > > > > > > > > > Well, I can just give you one user (multiple instances in the > > > > > codebase) that I know of which is why I brought it up. I don't know > > > > > anyone else using Commons Collections in their projects. Many projects > > > > > I am involved in use Groovy which has some nicer workarounds than the > > > > > stream variant I mentioned earlier. So, it's less critical for me, but > > > > > I thought Java users would appreciate the simpler form. > > > > > > > > > > Asking ChatGPT about Eclipse Collections flip() usage and inverse() > > > > > and invertFrom() for Guava points to Minecraft and Eclipse Xtext as > > > > > quick examples of usage. It goes on to say: > > > > > > > > > > > How to find more examples yourself > > > > > > > > > > > > Use GitHub code search (or grep over downloaded repos) with queries > > > > > > like: > > > > > > > > > > > > Multimaps.invertFrom( > > > > > > invertFrom( + Multimap > > > > > > flip() + org.eclipse.collections (or search for Multimap.flip()) > > > > > > > > > > > > Those queries will turn up dozens — often hundreds — of usages > > > > > > across OSS. > > > > > > > > > > > > > However, if you know that you will need the inverse, it's not > > > > difficult to build that in parallel. > > > > > > > > Are there any occasions where the inverse has to be built later from > > > > an existing Multimap? > > > > > > > > > Cheers, Paul. > > > > > > > > > > > > > > > On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold > > > > > wrote: > > > > > > > > > > > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski > > > > > > wrote: > > > > > > > > > > > > > > Hello. > > > > > > > > > > > > > Isn't it a "chicken-and-egg" question? > > > > > > > Isn't the purpose of a "common" library to implement well-defined > > > > > > > and > > > > > > > generally useful functionality, in the hope that it'll incite > > > > > > > code reuse? > > > > > > > Until said functionality is implemented, it obviously cannot be > > > > > > > used... > > > > > > > > > > > > No, it isn't. The use case comes first. If you can point to three > > > > > > existing projects that have had to implement this functionality > > > > > > already, and that would be willing to replace their existing code > > > > > > with > > > > > > a common library, then you have a case for implementing it here. > > > > > > Absent that, it is unlikely it will be adopted broadly enough to be > > > > > > worth the effort. > > > > > > > > > > > > -- > > > > > > Elliotte Rusty Harold > > > > > > [email protected] > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > - > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > >
Re: [Collections] Potential inverse method for multimaps
Okay, there doesn't seem to be a lot of interest, but I went ahead and created the PR anyway: https://github.com/apache/commons-collections/pull/665 If the decision is to close the PR, at least future users wanting such functionality might find the discussion and find something useful in the PR for their own codebases. Cheers, Paul. On Fri, Dec 12, 2025 at 8:54 PM Paul King wrote: > > On Fri, Dec 12, 2025 at 8:39 PM sebb wrote: > > > > On Thu, 11 Dec 2025 at 23:49, Paul King wrote: > > > > > > True, I guess an analysis of the above suggested searches could > > > reveal, in some cases, the sizes of the data and why the dozens or > > > hundreds of cases mentioned above chose to use the flip/inver** > > > methods instead of double storing the datasets. I would think small > > > immutable datasets could be suitable for double storing. For large > > > datasets, the storage requirements might be problematic. For mutable > > > sets, the double manipulations for a putAll (as one example) can > > > become messy. > > > > AFAICT, Eclipse Collections flip creates a new Map with the keys and > > values reversed. > > So no saving in storage. > > Certainly that would be true for cases where both the normal and the > inverse maps were always both needed and were created and used in a > short time span. In the scenarios I am using multimaps, the normal > data is more long-lived, and the inverse is only needed occasionally > when the user asks for certain "query" operations. > > > > Cheers, Paul. > > > > > > On Fri, Dec 12, 2025 at 8:19 AM sebb wrote: > > > > > > > > On Thu, 11 Dec 2025 at 20:57, Paul King > > > > wrote: > > > > > > > > > > Well, I can just give you one user (multiple instances in the > > > > > codebase) that I know of which is why I brought it up. I don't know > > > > > anyone else using Commons Collections in their projects. Many projects > > > > > I am involved in use Groovy which has some nicer workarounds than the > > > > > stream variant I mentioned earlier. So, it's less critical for me, but > > > > > I thought Java users would appreciate the simpler form. > > > > > > > > > > Asking ChatGPT about Eclipse Collections flip() usage and inverse() > > > > > and invertFrom() for Guava points to Minecraft and Eclipse Xtext as > > > > > quick examples of usage. It goes on to say: > > > > > > > > > > > How to find more examples yourself > > > > > > > > > > > > Use GitHub code search (or grep over downloaded repos) with queries > > > > > > like: > > > > > > > > > > > > Multimaps.invertFrom( > > > > > > invertFrom( + Multimap > > > > > > flip() + org.eclipse.collections (or search for Multimap.flip()) > > > > > > > > > > > > Those queries will turn up dozens — often hundreds — of usages > > > > > > across OSS. > > > > > > > > > > > > > However, if you know that you will need the inverse, it's not > > > > difficult to build that in parallel. > > > > > > > > Are there any occasions where the inverse has to be built later from > > > > an existing Multimap? > > > > > > > > > Cheers, Paul. > > > > > > > > > > > > > > > On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold > > > > > wrote: > > > > > > > > > > > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski > > > > > > wrote: > > > > > > > > > > > > > > Hello. > > > > > > > > > > > > > Isn't it a "chicken-and-egg" question? > > > > > > > Isn't the purpose of a "common" library to implement well-defined > > > > > > > and > > > > > > > generally useful functionality, in the hope that it'll incite > > > > > > > code reuse? > > > > > > > Until said functionality is implemented, it obviously cannot be > > > > > > > used... > > > > > > > > > > > > No, it isn't. The use case comes first. If you can point to three > > > > > > existing projects that have had to implement this functionality > > > > > > already, and that would be willing to replace their existing code > > > > > > with > > > > > > a common library, then you have a case for implementing it here. > > > > > > Absent that, it is unlikely it will be adopted broadly enough to be > > > > > > worth the effort. > > > > > > > > > > > > -- > > > > > > Elliotte Rusty Harold > > > > > > [email protected] > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > - > > > To un
Re: [Collections] Potential inverse method for multimaps
On Fri, Dec 12, 2025 at 8:39 PM sebb wrote: > > On Thu, 11 Dec 2025 at 23:49, Paul King wrote: > > > > True, I guess an analysis of the above suggested searches could > > reveal, in some cases, the sizes of the data and why the dozens or > > hundreds of cases mentioned above chose to use the flip/inver** > > methods instead of double storing the datasets. I would think small > > immutable datasets could be suitable for double storing. For large > > datasets, the storage requirements might be problematic. For mutable > > sets, the double manipulations for a putAll (as one example) can > > become messy. > > AFAICT, Eclipse Collections flip creates a new Map with the keys and > values reversed. > So no saving in storage. Certainly that would be true for cases where both the normal and the inverse maps were always both needed and were created and used in a short time span. In the scenarios I am using multimaps, the normal data is more long-lived, and the inverse is only needed occasionally when the user asks for certain "query" operations. > > Cheers, Paul. > > > > On Fri, Dec 12, 2025 at 8:19 AM sebb wrote: > > > > > > On Thu, 11 Dec 2025 at 20:57, Paul King wrote: > > > > > > > > Well, I can just give you one user (multiple instances in the > > > > codebase) that I know of which is why I brought it up. I don't know > > > > anyone else using Commons Collections in their projects. Many projects > > > > I am involved in use Groovy which has some nicer workarounds than the > > > > stream variant I mentioned earlier. So, it's less critical for me, but > > > > I thought Java users would appreciate the simpler form. > > > > > > > > Asking ChatGPT about Eclipse Collections flip() usage and inverse() > > > > and invertFrom() for Guava points to Minecraft and Eclipse Xtext as > > > > quick examples of usage. It goes on to say: > > > > > > > > > How to find more examples yourself > > > > > > > > > > Use GitHub code search (or grep over downloaded repos) with queries > > > > > like: > > > > > > > > > > Multimaps.invertFrom( > > > > > invertFrom( + Multimap > > > > > flip() + org.eclipse.collections (or search for Multimap.flip()) > > > > > > > > > > Those queries will turn up dozens — often hundreds — of usages across > > > > > OSS. > > > > > > > > > > However, if you know that you will need the inverse, it's not > > > difficult to build that in parallel. > > > > > > Are there any occasions where the inverse has to be built later from > > > an existing Multimap? > > > > > > > Cheers, Paul. > > > > > > > > > > > > On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold > > > > wrote: > > > > > > > > > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski > > > > > wrote: > > > > > > > > > > > > Hello. > > > > > > > > > > > Isn't it a "chicken-and-egg" question? > > > > > > Isn't the purpose of a "common" library to implement well-defined > > > > > > and > > > > > > generally useful functionality, in the hope that it'll incite code > > > > > > reuse? > > > > > > Until said functionality is implemented, it obviously cannot be > > > > > > used... > > > > > > > > > > No, it isn't. The use case comes first. If you can point to three > > > > > existing projects that have had to implement this functionality > > > > > already, and that would be willing to replace their existing code with > > > > > a common library, then you have a case for implementing it here. > > > > > Absent that, it is unlikely it will be adopted broadly enough to be > > > > > worth the effort. > > > > > > > > > > -- > > > > > Elliotte Rusty Harold > > > > > [email protected] > > > > > > > > > > - > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > - > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > - > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: [Collections] Potential inverse method for multimaps
On Thu, 11 Dec 2025 at 23:49, Paul King wrote: > > True, I guess an analysis of the above suggested searches could > reveal, in some cases, the sizes of the data and why the dozens or > hundreds of cases mentioned above chose to use the flip/inver** > methods instead of double storing the datasets. I would think small > immutable datasets could be suitable for double storing. For large > datasets, the storage requirements might be problematic. For mutable > sets, the double manipulations for a putAll (as one example) can > become messy. AFAICT, Eclipse Collections flip creates a new Map with the keys and values reversed. So no saving in storage. > Cheers, Paul. > > On Fri, Dec 12, 2025 at 8:19 AM sebb wrote: > > > > On Thu, 11 Dec 2025 at 20:57, Paul King wrote: > > > > > > Well, I can just give you one user (multiple instances in the > > > codebase) that I know of which is why I brought it up. I don't know > > > anyone else using Commons Collections in their projects. Many projects > > > I am involved in use Groovy which has some nicer workarounds than the > > > stream variant I mentioned earlier. So, it's less critical for me, but > > > I thought Java users would appreciate the simpler form. > > > > > > Asking ChatGPT about Eclipse Collections flip() usage and inverse() > > > and invertFrom() for Guava points to Minecraft and Eclipse Xtext as > > > quick examples of usage. It goes on to say: > > > > > > > How to find more examples yourself > > > > > > > > Use GitHub code search (or grep over downloaded repos) with queries > > > > like: > > > > > > > > Multimaps.invertFrom( > > > > invertFrom( + Multimap > > > > flip() + org.eclipse.collections (or search for Multimap.flip()) > > > > > > > > Those queries will turn up dozens — often hundreds — of usages across > > > > OSS. > > > > > > > However, if you know that you will need the inverse, it's not > > difficult to build that in parallel. > > > > Are there any occasions where the inverse has to be built later from > > an existing Multimap? > > > > > Cheers, Paul. > > > > > > > > > On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold > > > wrote: > > > > > > > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski > > > > wrote: > > > > > > > > > > Hello. > > > > > > > > > Isn't it a "chicken-and-egg" question? > > > > > Isn't the purpose of a "common" library to implement well-defined and > > > > > generally useful functionality, in the hope that it'll incite code > > > > > reuse? > > > > > Until said functionality is implemented, it obviously cannot be > > > > > used... > > > > > > > > No, it isn't. The use case comes first. If you can point to three > > > > existing projects that have had to implement this functionality > > > > already, and that would be willing to replace their existing code with > > > > a common library, then you have a case for implementing it here. > > > > Absent that, it is unlikely it will be adopted broadly enough to be > > > > worth the effort. > > > > > > > > -- > > > > Elliotte Rusty Harold > > > > [email protected] > > > > > > > > - > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > - > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > - > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: [Collections] Potential inverse method for multimaps
I did hear back from the maintainers of Eclipse Collections and flip() was added in EC due to usage in clients from the investment banking/finance sector. I believe that would have all been closed source, so could be added to the OSS cases. Cheers, Paul. On Fri, Dec 12, 2025 at 6:57 AM Paul King wrote: > > Well, I can just give you one user (multiple instances in the > codebase) that I know of which is why I brought it up. I don't know > anyone else using Commons Collections in their projects. Many projects > I am involved in use Groovy which has some nicer workarounds than the > stream variant I mentioned earlier. So, it's less critical for me, but > I thought Java users would appreciate the simpler form. > > Asking ChatGPT about Eclipse Collections flip() usage and inverse() > and invertFrom() for Guava points to Minecraft and Eclipse Xtext as > quick examples of usage. It goes on to say: > > > How to find more examples yourself > > > > Use GitHub code search (or grep over downloaded repos) with queries like: > > > > Multimaps.invertFrom( > > invertFrom( + Multimap > > flip() + org.eclipse.collections (or search for Multimap.flip()) > > > > Those queries will turn up dozens — often hundreds — of usages across OSS. > > > Cheers, Paul. > > > On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold > wrote: > > > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski > > wrote: > > > > > > Hello. > > > > > Isn't it a "chicken-and-egg" question? > > > Isn't the purpose of a "common" library to implement well-defined and > > > generally useful functionality, in the hope that it'll incite code reuse? > > > Until said functionality is implemented, it obviously cannot be used... > > > > No, it isn't. The use case comes first. If you can point to three > > existing projects that have had to implement this functionality > > already, and that would be willing to replace their existing code with > > a common library, then you have a case for implementing it here. > > Absent that, it is unlikely it will be adopted broadly enough to be > > worth the effort. > > > > -- > > Elliotte Rusty Harold > > [email protected] > > > > - > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: [Collections] Potential inverse method for multimaps
True, I guess an analysis of the above suggested searches could reveal, in some cases, the sizes of the data and why the dozens or hundreds of cases mentioned above chose to use the flip/inver** methods instead of double storing the datasets. I would think small immutable datasets could be suitable for double storing. For large datasets, the storage requirements might be problematic. For mutable sets, the double manipulations for a putAll (as one example) can become messy. Cheers, Paul. On Fri, Dec 12, 2025 at 8:19 AM sebb wrote: > > On Thu, 11 Dec 2025 at 20:57, Paul King wrote: > > > > Well, I can just give you one user (multiple instances in the > > codebase) that I know of which is why I brought it up. I don't know > > anyone else using Commons Collections in their projects. Many projects > > I am involved in use Groovy which has some nicer workarounds than the > > stream variant I mentioned earlier. So, it's less critical for me, but > > I thought Java users would appreciate the simpler form. > > > > Asking ChatGPT about Eclipse Collections flip() usage and inverse() > > and invertFrom() for Guava points to Minecraft and Eclipse Xtext as > > quick examples of usage. It goes on to say: > > > > > How to find more examples yourself > > > > > > Use GitHub code search (or grep over downloaded repos) with queries like: > > > > > > Multimaps.invertFrom( > > > invertFrom( + Multimap > > > flip() + org.eclipse.collections (or search for Multimap.flip()) > > > > > > Those queries will turn up dozens — often hundreds — of usages across OSS. > > > > However, if you know that you will need the inverse, it's not > difficult to build that in parallel. > > Are there any occasions where the inverse has to be built later from > an existing Multimap? > > > Cheers, Paul. > > > > > > On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold > > wrote: > > > > > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski > > > wrote: > > > > > > > > Hello. > > > > > > > Isn't it a "chicken-and-egg" question? > > > > Isn't the purpose of a "common" library to implement well-defined and > > > > generally useful functionality, in the hope that it'll incite code > > > > reuse? > > > > Until said functionality is implemented, it obviously cannot be used... > > > > > > No, it isn't. The use case comes first. If you can point to three > > > existing projects that have had to implement this functionality > > > already, and that would be willing to replace their existing code with > > > a common library, then you have a case for implementing it here. > > > Absent that, it is unlikely it will be adopted broadly enough to be > > > worth the effort. > > > > > > -- > > > Elliotte Rusty Harold > > > [email protected] > > > > > > - > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > - > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: [Collections] Potential inverse method for multimaps
On Thu, 11 Dec 2025 at 20:57, Paul King wrote: > > Well, I can just give you one user (multiple instances in the > codebase) that I know of which is why I brought it up. I don't know > anyone else using Commons Collections in their projects. Many projects > I am involved in use Groovy which has some nicer workarounds than the > stream variant I mentioned earlier. So, it's less critical for me, but > I thought Java users would appreciate the simpler form. > > Asking ChatGPT about Eclipse Collections flip() usage and inverse() > and invertFrom() for Guava points to Minecraft and Eclipse Xtext as > quick examples of usage. It goes on to say: > > > How to find more examples yourself > > > > Use GitHub code search (or grep over downloaded repos) with queries like: > > > > Multimaps.invertFrom( > > invertFrom( + Multimap > > flip() + org.eclipse.collections (or search for Multimap.flip()) > > > > Those queries will turn up dozens — often hundreds — of usages across OSS. > However, if you know that you will need the inverse, it's not difficult to build that in parallel. Are there any occasions where the inverse has to be built later from an existing Multimap? > Cheers, Paul. > > > On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold > wrote: > > > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski > > wrote: > > > > > > Hello. > > > > > Isn't it a "chicken-and-egg" question? > > > Isn't the purpose of a "common" library to implement well-defined and > > > generally useful functionality, in the hope that it'll incite code reuse? > > > Until said functionality is implemented, it obviously cannot be used... > > > > No, it isn't. The use case comes first. If you can point to three > > existing projects that have had to implement this functionality > > already, and that would be willing to replace their existing code with > > a common library, then you have a case for implementing it here. > > Absent that, it is unlikely it will be adopted broadly enough to be > > worth the effort. > > > > -- > > Elliotte Rusty Harold > > [email protected] > > > > - > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: [Collections] Potential inverse method for multimaps
Well, I can just give you one user (multiple instances in the codebase) that I know of which is why I brought it up. I don't know anyone else using Commons Collections in their projects. Many projects I am involved in use Groovy which has some nicer workarounds than the stream variant I mentioned earlier. So, it's less critical for me, but I thought Java users would appreciate the simpler form. Asking ChatGPT about Eclipse Collections flip() usage and inverse() and invertFrom() for Guava points to Minecraft and Eclipse Xtext as quick examples of usage. It goes on to say: > How to find more examples yourself > > Use GitHub code search (or grep over downloaded repos) with queries like: > > Multimaps.invertFrom( > invertFrom( + Multimap > flip() + org.eclipse.collections (or search for Multimap.flip()) > > Those queries will turn up dozens — often hundreds — of usages across OSS. Cheers, Paul. On Fri, Dec 12, 2025 at 1:23 AM Elliotte Rusty Harold wrote: > > On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski wrote: > > > > Hello. > > > Isn't it a "chicken-and-egg" question? > > Isn't the purpose of a "common" library to implement well-defined and > > generally useful functionality, in the hope that it'll incite code reuse? > > Until said functionality is implemented, it obviously cannot be used... > > No, it isn't. The use case comes first. If you can point to three > existing projects that have had to implement this functionality > already, and that would be willing to replace their existing code with > a common library, then you have a case for implementing it here. > Absent that, it is unlikely it will be adopted broadly enough to be > worth the effort. > > -- > Elliotte Rusty Harold > [email protected] > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: [Collections] Potential inverse method for multimaps
On Thu, Dec 11, 2025 at 3:06 PM Gilles Sadowski wrote: > > Hello. > Isn't it a "chicken-and-egg" question? > Isn't the purpose of a "common" library to implement well-defined and > generally useful functionality, in the hope that it'll incite code reuse? > Until said functionality is implemented, it obviously cannot be used... No, it isn't. The use case comes first. If you can point to three existing projects that have had to implement this functionality already, and that would be willing to replace their existing code with a common library, then you have a case for implementing it here. Absent that, it is unlikely it will be adopted broadly enough to be worth the effort. -- Elliotte Rusty Harold [email protected] - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: [Collections] Potential inverse method for multimaps
Hello. Le jeu. 11 déc. 2025 à 14:23, Elliotte Rusty Harold a écrit : > > Standard question for new functionality: Who will use it? Can you > point to specific projects that will replace existing code with this > new commons method? > > Utility libraries have a habit of collecting a lot of unused cruft > that was added because it seemed logical, but that did not have an > actual, non-hypothetical need. Isn't it a "chicken-and-egg" question? Isn't the purpose of a "common" library to implement well-defined and generally useful functionality, in the hope that it'll incite code reuse? Until said functionality is implemented, it obviously cannot be used... I think that a distinction can be made (?) between "cruft" (used or not) and potentially useful (even if we cannot enforce usage). Regards, Gilles > [...] >> [...] - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: [Collections] Potential inverse method for multimaps
Standard question for new functionality: Who will use it? Can you
point to specific projects that will replace existing code with this
new commons method?
Utility libraries have a habit of collecting a lot of unused cruft
that was added because it seemed logical, but that did not have an
actual, non-hypothetical need.
Unless you can point to specific code where you need to use this, I
wouldn't do it.
On Thu, Dec 11, 2025 at 12:03 PM Paul King wrote:
>
> Hi folks,
>
> I noticed that Collections doesn't have the equivalent of Guava's
> inverse() for ImmutableMultimaps or Eclipse Collections flip() for its
> multimaps. Would there be interest in looking at a PR for such
> functionality?
>
> Here is an example:
>
> Map> citiesLived = new HashSetValuedHashMap<>(4);
> citiesLived.put("Alice", "N.Y.");
> citiesLived.put("Alice", "L.A.");
> citiesLived.put("Alice", "Chicago");
> citiesLived.put("Bob", "N.Y.");
> citiesLived.put("Cara", "L.A.");
> citiesLived.put("Cara", "Chicago");
>
> Here is the proposed syntax:
>
> Map> inverted = citiesLived.inverse()
>
> The current way to get this would be iterating over entries and
> creating the inverse multimap manually or use streams like below:
>
> Map> inverted = citiesLived.entries().stream()
> .collect(Collectors.groupingBy(
> Map.Entry::getValue,
> // group by city
> Collectors.mapping(Map.Entry::getKey, // collect names
>Collectors.toSet())
> ));
>
> System.out.println("Original: " + citiesLived);
> System.out.println("Inverted: " + inverted);
>
> Output would be:
> Original: {Cara=[L.A., Chicago], Bob=[N.Y.], Alice=[L.A., N.Y., Chicago]}
> Inverted: {N.Y.=[Bob, Alice], Chicago=[Cara, Alice], L.A.=[Cara, Alice]}
>
> Thoughts?
>
> Cheers, Paul.
>
> -
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
--
Elliotte Rusty Harold
[email protected]
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
[Collections] Potential inverse method for multimaps
Hi folks,
I noticed that Collections doesn't have the equivalent of Guava's
inverse() for ImmutableMultimaps or Eclipse Collections flip() for its
multimaps. Would there be interest in looking at a PR for such
functionality?
Here is an example:
Map> citiesLived = new HashSetValuedHashMap<>(4);
citiesLived.put("Alice", "N.Y.");
citiesLived.put("Alice", "L.A.");
citiesLived.put("Alice", "Chicago");
citiesLived.put("Bob", "N.Y.");
citiesLived.put("Cara", "L.A.");
citiesLived.put("Cara", "Chicago");
Here is the proposed syntax:
Map> inverted = citiesLived.inverse()
The current way to get this would be iterating over entries and
creating the inverse multimap manually or use streams like below:
Map> inverted = citiesLived.entries().stream()
.collect(Collectors.groupingBy(
Map.Entry::getValue,
// group by city
Collectors.mapping(Map.Entry::getKey, // collect names
Collectors.toSet())
));
System.out.println("Original: " + citiesLived);
System.out.println("Inverted: " + inverted);
Output would be:
Original: {Cara=[L.A., Chicago], Bob=[N.Y.], Alice=[L.A., N.Y., Chicago]}
Inverted: {N.Y.=[Bob, Alice], Chicago=[Cara, Alice], L.A.=[Cara, Alice]}
Thoughts?
Cheers, Paul.
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
