Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Why does Java's Collection.size() return an int? This limits the size of collections to just over 2 billion entries. With the rapidly increasing amounts of memory available to us, this seems a little short-sighted - no?


migration rejected from Oct 24 at 21:10

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by MichaelT, Snowman, GlenH7, durron597, gnat Oct 24 at 21:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

A lot of libraries (not just in Java) have this problem... – Mysticial Sep 16 '11 at 1:06
"I'm going to design this Thing. Let's see... I'll make it support a bazabegig items. Yeah. Oh, wait! Someday somebody might want to add a degahedricbazigadon items - I'll design it for that instead! But what if they want to add a beezelbubdoodlezigahedron items someday?" Where do you stop to actually have something you can use? And why wouldn't you consider 2 billion items in a Collection to be enough? If you have more items than that, is a Collection really the best way to store and use it? Is the item count really the limit, or the data itself? – Ken White Sep 16 '11 at 1:14
Is the number of items really the limit? Every collection I've ever needed (not Java) contained more than a single byte of data, so 2 billion * (multiple bytes per item) is the actual issue, not the fact that it returns an int. Two billion items in a Collection doesn't seem to be a limit, even if the individual item only consumed a small amount of memory. (And in the early '90s, 2 billion bytes of memory was huge - PCs then had RAM sizes in MB. I know - in '94 I got my first monster PC with 16MB RAM and a 1GB SCSI drive. The drive was $1000 used, and the RAM was too.) – Ken White Sep 16 '11 at 1:26
@Ken, when they designed Java did they assume that Moore's law would suddenly stop applying with regard to memory? Perhaps they assumed that nobody would be using Java 15 years later. In either case it would have been a short-sighted assumption. Furthermore, as I've mentioned elsewhere, nothing about the Collection interface assumes that the data the collection contains must be stored in RAM. – sanity Sep 16 '11 at 1:30
I don't actually know Java very well, but couldn't you just create a Collection of Collections? That would give you about two billion Collections of two billion items each. – Kusalananda Sep 16 '11 at 8:43

4 Answers 4

I think they did the right thing. Like everything else to do with computers Algorithms don't necessarily scale.

An hash/storage algorithm which handles a 10,000 items nicely is probably going to die long before it hits 500,000,000 items.

And its not just about Moores law. Core counts are doubling about every five years and while a single threaded "copy" is OK on a set of a few thousand for a set of millions you would want to activate all the available cores.

I think the original "collections" are still fit for purpose as most collections in the real world will hold less than a 1000 entries, and there are relatively few > 10,000.

Someday just like BigDecimal and BigNumber we will have BigHash and HugeArray.


Obviously, Java Collection is mostly made for collections that contain 2 billion entries at most. If you have more entries to manage, chances are that you need something else than, say, an ArrayList. Nothing keeps you from implementing and using such a collection. The only issue is that the standard collection interface is not the best possible match for that beast.


Why does Java's Collection.size() return an int?

The real answer is to maintain backwards compatibility with older versions of Java.

The size() method was first implemented in the days when all JVMs were 32 bit. In that environment, a size() method that returned a long would have been weird.

Now 64bit JVMs are commonplace, and huge collections are at least feasible. But if they changed size() now to return a long, it would break binary compatibility for millions of existing Java programs.

Now you could argue with some justifications that collections that big have implementation and performance issues. Those issues could be worked by implementing special collection classes. If you do this, then you can also give the class (say) a longSize() method and alternate versions of get, insert, remove and so on that use 64 bit indexes.


The javadoc for the Collection interface says this about size():

Returns the number of elements in this collection. If this collection contains more than Integer.MAX_VALUE elements, returns Integer.MAX_VALUE.

Therefore there isn't any inherent limit on the size of a Collection.

indeed there isn't, but the items with indices > Integer.MAX_VALUE can't be addressed by index number. They might be addressable through iterators, which of course gets extremely slow for such massive amounts of data. – jwenting Sep 16 '11 at 7:15
@jwenting a related question then would be "why do the classes in the Collections Framework only accept an int as an index?" Note that the Collection interface doesn't have any methods that directly index an item. – cgull Sep 16 '11 at 7:55
now THAT would be a good question :) And one that might have historical reasons if for example the original implementation of the classes involved did indeed have a limit of 2^32 on the size of the collection. – jwenting Sep 16 '11 at 11:57
@jwenting: Is iterating over a Java collection always slower if you use iterators? – fredoverflow Dec 25 '11 at 12:42