22
Feb
2011
Feb
2011
6
Reasons to call .isEmpty on collections
I’ve seen many times code like the one below:
1 | if (collection.size() > 0) { ... } |
There is just something which inherently “clicks” with most programmers minds when they think “non-empty”. There is however a method which is more appropriate in most of the cases: isEmpty:
1 | if (!collection.isEmpty()) { ... } |
The top reasons for using isEmpty rather than size would be:
- it is more expressive (the code is easier to read and to maintain)
- it is faster, in some cases by orders of magnitude. Two examples from the JDK where this is extremely visible would be the ConcurrentLinkedQueue and NavigableMap / NavigableSet. All of these implement the “size” method by iterating trough the collection and because of this, calling size gets increasingly slower as the number of elements increase
Todays source code performs a comparative benchmark between small (10 element) and large (1 000 000 elements) collections by timing the calls to the size and is empty methods. While benchmarks and especially micro-benchmarks needs be taken with a large grain of salt 
, these tests show that there is at least a factor of 10x difference in time when calling the size method and there is very little difference when calling the isEmpty method.
Standard postscript: this is a guest-post by Attila Balazs (aka Cd-MaN). The text of the article is available under the CC-BY-SA license. The associated source code is available under public domain, CC0 or the MIT/X License, depending on your preference.
I personally appreciate the initiative of this blog and this template article. This format – short Java tips – is perfect for the developer which is always in a hurry.
I will enjoy reading this blog. Good luck!
Pingback: Deathy's blog » Blog Archive » On Readable Code
Thank you to you both! Hopefully this collection of articles will become more and more useful as time passes!
Hi,
I’m afraid I have to disagree with this: “NavigableMap / NavigableSet. All of these implement the “size” method by iterating trough the collection and because of this, calling size gets increasingly slower as the number of elements increase”.
The TreeMap implementation of size() (which is used by TreeSet) just returns this.size
Regarding ConcurrentLinkedQueue you were right.
Thank you for the clarification. Probably I was thinking about about subsets (like the ones obtained by TreeSet.headSet).
Pingback: Razón para llamar a .isEmpty en Collections | Codecriticon