why .size() is not getSize() on collections

Question

I have been using Java for quite some time and am still puzzled by this naming of API. Why is it like that?

For example when you have one instance of ArrayList it has a property of how much objects are added to the list. To get this property you call .size() and not getSize() which would be more along the line of what you are actually trying to do. You are trying to read a value of the property of this list, not do some operation on it. I guess internally "sizing" this list is probably much more complicated then just reading a single variable but that is implantation detail and the user of the object should not care about that.

It's also three characters shorter and a fairly common operation. :-) — Platinum Azure, May 23 '14 at 12:51
Yes that is my though about it also, but aren't they breaking the convention by doing that? — Igor Čordaš, May 23 '14 at 12:52
maybe they wanted it to be more 'like' it is with an array, while with an array for 'length' you don't have a 'getLength()' method but a property 'length'. — Stultuske, May 23 '14 at 12:53
@hexafraction beat me to answering the question with the same answer I was thinking of! :') — TheBrenny, May 23 '14 at 12:55
There is no `setSize` method and collections are not beans so `size` is perfectly fine. — Pshemo, May 23 '14 at 12:55
possible duplicate of [Why doesn't ArrayList have getSize() instead of size()?](http://stackoverflow.com/questions/8772204/why-doesnt-arraylist-have-getsize-instead-of-size) — Kevin Panko, May 23 '14 at 13:51
Hu. This shouldn't be closed as "primarily opinion based", since there exists a description of the rationale for this by the designers of the Java collection framework -- no opinion involved here (except of those of the designers). But it should be closed as "duplicate of" (sorry, didn't check before answering). Anyway, closed is closed. — Dirk, May 23 '14 at 14:17

score 12 · Accepted Answer · answered May 23 '14 at 12:55

12

Verbatim quote from the "Java Collections API Design FAQ"

Why didn't you use "Beans-style names" for consistency?

While the names of the new collections methods do not adhere to the "Beans naming conventions", we believe that they are reasonable, consistent and appropriate to their purpose. It should be remembered that the Beans naming conventions do not apply to the JDK as a whole; the AWT did adopt these conventions, but that decision was somewhat controversial. We suspect that the collections APIs will be used quite pervasively, often with multiple method calls on a single line of code, so it is important that the names be short. Consider, for example, the Iterator methods. Currently, a loop over a collection looks like this:

for (Iterator i = c.iterator(); i.hasNext(); ) System.out.println(i.next());

Everything fits neatly on one line, even if the Collection name is a long expression. If we named the methods "getIterator", "hasNextElement" and "getNextElement", this would no longer be the case. Thus, we adopted the "traditional" JDK style rather than the Beans style.

answered May 23 '14 at 12:55

Dirk

30,623
8
82
102

This is exactly the kind of explanation I was looking for. Thank you. – Igor Čordaš May 23 '14 at 12:58
:L Never realised how lazy Oracle was. If something is to stay on the same line it generally refers to the physical screen's size, no? And plus, what difference does it make? Even if it fits nicely on the same line it doesn't have the ... umph(?) that a core Java class should have. Shun Oracle, shun. – TheBrenny May 23 '14 at 13:01
Also think about it like this, yes it's shorter to write but if you try writing getSize() first (as many would agree would be logical) and then you need to change it to size() you lose all the benefits of 3 letter shorter word. This still happens to me all the time and I have been programming in Java for 4-5 years, I guess it happens even to people with more experience. – Igor Čordaš May 23 '14 at 13:07
Oracle? Java was originally designed, developed, maintained and guarded by Sun Microsystems. Oracle only bought the blame. – Gimby May 23 '14 at 13:27
The standard library has never been consistent here; IIRC, the "beans" stuff came late. Consider: `Object.hashCode()`, `String.length()`, `Vector.size()` (since JDK 1.0), `Hashtable.elements()`, etc. – Dirk May 23 '14 at 14:10
@Gimby, but pretty much all the new libraries were made by Oracle? – TheBrenny May 25 '14 at 12:06
@mastercork889, what's "new"? The Java collection framework appeared with JDK 1.2 (around 1998 according to Wikipedia), which pretty much makes Sun responsible here. Also, a lot of the "standard" libraries are conceived of by expert commitees within the JCP process, which at least on paper are independent of Oracle and include external expertise. – Dirk May 26 '14 at 09:33
@Dirk, well hey! You learn something new every day right? – TheBrenny May 26 '14 at 22:50
A collection has a 'size', it doesn't have any you could measure as its 'getsize'. When I write `n = c.size()` this perfectly reflects my thinking - I am setting n to the size of c. 'get' is just noise. – user16632363 Oct 04 '21 at 00:50

score 4 · Answer 2 · edited May 23 '14 at 12:58

A likely reason for such naming is that in many cases the naming is unambiguous and terse. Imagine a POJO:

public class Human {
    String name;
    //accessors and mutators
}

Imagine having two methods, String name() and void name(String). One gets the name, the other sets it.

In these library classes, most names are unambiguous. A user of the class cannot set the size, except through adding or removing elements, so simply size is valid; one does not set the size, the class 'alters' the size. Other examples are the Map's keySet, which returns a set of entries. It does not make sense to give a map a set of keys without passing in a map via addAll, or adding them one-by-one.

Other notable examples include:

String#length. An immutable string's length may not be set.
More to be added

It is important to note that classes like Socket use prefixes such as get, set, and is.

Good points. You even suggested the Socket classes and that is exactly what I was thing about when asking this question. A)Because they aren't beans but still follow the convention B)Have been in Java for quite a long time like Collections C)Are often used — Igor Čordaš, May 23 '14 at 13:03

why .size() is not getSize() on collections

2 Answers2