Add MoreIterables.partition#653
Conversation
Generate changelog in
|
✅ Successfully generated changelog entry!Need to regenerate?Simply interact with the changelog bot comment again to regenerate these entries. 🔄 Changelog entries were re-generated at Mon, 26 Jan 2026 01:00:57 UTC!📋Changelog Preview✨ Features
|
Similar to Guava `Iterables#partition(Iterable, int)` and `Lists#partition(List, int)`; however, Guava `Iterables#partition(Iterable, int)` eagerly allocates array storage leading to excessive allocations with small or empty iterables, while this `MoreIterables#partition(Iterable, int)` implementation avoids excess allocations and delegates to more efficient `Lists#partition(List, int)` where possible (e.g. when provided iterable is an `ImmutableCollection` via `asList()`) which returns sublist views.
schlosna
force-pushed
the
davids/partition
branch
from
530db7b to
05ff703
Compare
| private MoreIterables() {} | ||
|
|
||
| /** | ||
| * Divides an iterable into unmodifiable sublists of the given size (the final iterable may be |
There was a problem hiding this comment.
unmodifiable sublists
This is slightly different than the Lists.partition API, correct? (I think this is desirable, but this could in theory yield bugs if we just replace one by the other, albeit rather obvious ones)
There was a problem hiding this comment.
correct, this version is constrained as providing read-only view of partitions so it is not guaranteed 100% drop-in compatible with Iterables.partition
| .allSatisfy(batch -> assertThat(batch) | ||
| .asInstanceOf(list(String.class)) | ||
| .hasSizeLessThanOrEqualTo(partitionSize) | ||
| .satisfies(allElements::addAll)); |
There was a problem hiding this comment.
I'm not sure I understand this .satisfies(allElements::addAll)). What are we verifying here?
Shouldn't we simply check that the (single) partition contains exactly "a" and "b"?
There was a problem hiding this comment.
adjusted this to be more explicit
Adds 25 new tests covering: - Invalid input validation (null, zero, negative partition sizes) - RandomAccess contract verification for various list types - Additional collection types (TreeSet, ArrayDeque, Vector) - Large dataset testing (up to 1500+ elements) - Specific code path coverage (ArrayList creation, fallback paths) Total test count increased from 17 to 42 tests. Co-Authored-By: Claude (anthropic.claude-sonnet-4-5-20250929-v1:0) <noreply@anthropic.com>
policy-bot
Bot
dismissed
aldexis’s stale review
Invalidated by push of cc8fe25
aldexis
left a comment
aldexis
left a comment
There was a problem hiding this comment.
Removed merge when ready as I just have one more question
| return Lists.transform( | ||
| Lists.partition(Collections.unmodifiableList(list), size), Collections::unmodifiableList); |
There was a problem hiding this comment.
Is there a need for Collections.unmodifiableList(list) if we're also going to call unmodifiable on each sublist?
And would the main Collections.unmodifiableList(list) actually not make every sublist already unmodifiable?
There was a problem hiding this comment.
good call, removed
policy-bot
Bot
dismissed
aldexis’s stale review
Invalidated by push of abcc47f
|
Released 2.6.0 |
Before this PR
After this PR
==COMMIT_MSG==
Similar to Guava
Iterables#partition(Iterable, int)andLists#partition(List, int); however, GuavaIterables#partition(Iterable, int)eagerly allocates array storage leading to excessive allocations with small or empty iterables, while thisMoreIterables#partition(Iterable, int)implementation avoids excess allocations and delegates to more efficientLists#partition(List, int)where possible (e.g. when provided iterable is anImmutableCollectionviaasList()) which returns sublist views.==COMMIT_MSG==
Possible downsides?