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

Question

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?

Answer 1

The vast majority of applications uses collection sizes much less than that. A generic class should be designed to cover the most common cases, not the most extreme ones. A specialized collection class for very large collections will probably be added at some point.

Answer 2

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.

Answer 3

IMO people can reasonably disagree about whether int was the right compromise. However, there is nothing stopping you from implementing an interface that redefines size() to mean a minimum size. See how ConcurrentHashMap defines size.

The point is when you have collections of billions of elements, the precise size is most likely unimportant. A sense of the size will most likely get you there.

As a sidenote, precise counts often get expensive, and is why ! a.empty() is a much better expression than a.size() > 0 when dealing with collections.

Answer 4

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.

Answer 5

Worrying about index numbers is old fashioned. The future looks more like the below:

interface Function < T >
{
     void call ( T t ) ;
}

class Functions
{
     static void apply ( Iterable < T > iterable , Function < T > func )
     {
          for ( T t : iterable )
          {
                func . call ( t ) ;
          }
     }
}

Now that I think about it. They have already implemented a suitable collection - Map.

1. If you want a list of type V indexed by Integer use the existing List<V> class or use Map<Integer,V>
2. If you want a list of type V indexed by Long use Map<Long,V>.
3. If you want a list of type V indexed by BigInteger use Map<BigInteger,V>.

Answer 6

And who knows? Maybe when 2 billion is too small, they would have updated Java so an int holds more, or make a new primitive type.

Answer 7

there is a problem to store all array values into RAM so such big lists will cause usage of swap file and make system too slow, i think it is a bad idea. You'd better use more suitable structures to store such amount of data

Answer 8

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.

Answer 9

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.