Sized

[Mike Duigou]

One of the changes in Sized recently was that we removed all claims about cost of determining the size. Yep, it may be O(n). It is still useful to know that an Iterable can determine it's size and that size() implementation is at least as good as getting an iterator and counting the items. It's almost certainly better actually for for both performance and concurrency reasons.

Point taken though that if an Iterable is expensive to count it should be providing alternatives for getting an efficient Spliterator.

Mike

On Nov 2 2012, at 15:27 , Kevin Bourrillion wrote:

> My mistake: CHM only has to walk through every *segment* to add up the
> size, and I was thinking of it as actually traversing every element.
> 
> In any event. It's undeniably true that there are numerous implementations
> of Collection out there that don't know their size without completely
> iterating themselves. I still say that if there's any value in Sized, it
> lies in making those implementations *not* implement it while others do.
> 
> 
> 
> On Fri, Nov 2, 2012 at 3:22 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> Of course, some collections, like the key set of a ConcurrentHashMap,
>>> don't know their size any more than a garden-variety Iterable does.
>>> 
>> 
>> That's not exactly true.  In the absence of interference from concurrent
>> modification, the key set of a CHM absolutely knows its size.  It's just
>> that in the presence of interference, the reported size may be stale by the
>> time you receive it.
>> 
> 
> 
> 
> -- 
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com