Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lists.partition() gives incorrect result when partition size is Integer.MAX_VALUE #616

Closed
gissuebot opened this issue Oct 31, 2014 · 8 comments
Assignees
Labels
status=fixed type=defect Bug, not working as expected
Milestone

Comments

@gissuebot
Copy link

Original issue created by qforce.bak on 2011-05-02 at 07:06 PM


Hello,

It seems the method Lists.partition() behaves incorrectly when given a partition size of Integer.MAX_VALUE or Integer.MAX_VALUE - 1. The following snippet (based on Guava r08) demonstrates this:

List<String> list = Arrays.asList("a", "b", "c");
for (int i = 0; i < 5; i++) {
    List<List<String>> partition = Lists.partition(list, Integer.MAX_VALUE - i);
    System.out.println("size=" + partition.size() + " for i=" + i);
}

The console output is:

size=-1 for i=0
size=-1 for i=1
size=1 for i=2
size=1 for i=3
size=1 for i=4

I would expect size=1 if i=0 or i=1.

Best regards
Tran Nam Quang

@gissuebot
Copy link
Author

Original comment posted by boppenheim@google.com on 2011-05-04 at 07:00 AM


The behavior is actually whenever you give a partition size >= Integer.MAX_VALUE - (list.size() - 2).

On first thought, it seems odd to pass in values like Integer.MAX_VALUE. However, I guess you might be using MAX_VALUE to mean "give me a single partition". What is the use case where you want that though?

I suppose we could special case when the partition size is >= to the size of the list. I'm not sure if its worth the extra logic or not.

@gissuebot
Copy link
Author

Original comment posted by qforce.bak on 2011-05-04 at 08:11 AM


I came across this oddity while I was working on an SWT-based table viewer that supports pagination. Internally, the table viewer uses Lists.partition() to split its input elements into pages of a fixed size. By default, the page size is set to Integer.MAX_VALUE so that the table viewer behaves like one without pagination support, i.e. by default it always displays a single page, just like an ordinary table viewer.

@gissuebot
Copy link
Author

Original comment posted by finnw1 on 2011-05-04 at 09:12 AM


@boppenheim, the special-casing you describe will not solve the problem for all cases. Consider:

Lists.partition(Collections.nCopies(0x40000001, null), 0x40000000);

Here the partition size is smaller than the list, but the overflow still occurs.

@gissuebot
Copy link
Author

Original comment posted by finnw1 on 2011-05-04 at 09:24 AM


See this StackOverflow question for alternative ways to calculate the size that do not suffer from this bug:

http://stackoverflow.com/questions/17944/how-to-round-up-the-result-of-integer-division

This example is in C#, but everything here is also applicable to Java.

@gissuebot
Copy link
Author

Original comment posted by kevinb@google.com on 2011-05-05 at 02:09 AM


(No comment entered for this change.)


Status: Accepted

@gissuebot
Copy link
Author

Original comment posted by kevinb@google.com on 2011-07-13 at 06:18 PM


(No comment entered for this change.)


Status: Triaged

@gissuebot
Copy link
Author

Original comment posted by kevinb@google.com on 2011-07-13 at 07:25 PM


(No comment entered for this change.)


Status: Accepted
Labels: Type-Defect

@gissuebot
Copy link
Author

Original comment posted by wasserman.louis on 2011-08-22 at 03:52 PM


(No comment entered for this change.)


Status: Fixed
Owner: wasserman.louis
Labels: Milestone-Release10

@gissuebot gissuebot added type=defect Bug, not working as expected status=fixed migrated labels Oct 31, 2014
@cgdecker cgdecker modified the milestone: 10.0 Nov 1, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status=fixed type=defect Bug, not working as expected
Projects
None yet
Development

No branches or pull requests

3 participants