Settle on an interface for Futures.allAsList/successfulAsList (and Google-internal allAsMap/successfulAsMap)

[GoogleCodeExporter]

1. Are there better names? (Do they deserve the *same* name with disambiguating 
parameters? Do they at least deserve names that are near one another 
alphabetically?) Here's an internal-only doc with some discussion: 
https://docs.google.com/a/google.com/document/d/1Ry0Jx0tIJ8zFX9TnH6dbVCRGlYwrlky
iyekSYnay1VA/edit ("Possible rename of bulk Future methods")

2. Would successfulAsList be better if it returned a list containing only the 
successes rather than a list containing interleaves successes and nulls? 
(Previously, people might have wanted to match up indexes (though IIRC my 
survey showed that few if any users were doing this). Nowadays, they can use 
successfulAsMap, which makes it easier to associate values with keys (which is 
probably more natural than associating them with indexes, anyway.) (Less 
plausible advantage: A user might really want to distinguish between "returned 
null" and "failed." This would let him do that, as the "failed" entries would 
go away.) Another option is to add a third method with the failures stripped, 
but I doubt we'd want to bother.

3. When an allAsList input fails, should we cancel the other inputs? Should 
this be configurable? Here's an internal-only thread with some discussion: 
https://groups.google.com/a/google.com/d/topic/java-users/9utRs2xAafk/discussion

Original issue reported on code.google.com by cpov...@google.com on 29 Aug 2013 at 9:11

[GoogleCodeExporter]

An internal user would like to be able to access the result as a 
Future<ImmutableList<V>> rather than a 
Future<PlainListThatHappensToBeImpossibleToMutate<V>>. He's using a framework 
that requires known immutable objects. He can transform(), of course, but if we 
make change (2), this would be an opportunity to switch to ImmutableList (at 
the cost of some verbosity to users who don't care).

An additional feature to consider is some kind of configuration of logging (or, 
more generally, of handling of failures). Our current policy can be a bit 
spammy, but we would fear dropping important messages if we turned logging off 
universally.

This still doesn't make the API clear. Future<ImmutableList<Foo>> f = 
Futures.collect(list).allMustSucceed(), etc.? There are many options.

Original comment by cpov...@google.com on 13 Aug 2014 at 1:49

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:12

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:17

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit