Why in Java is the size of an array an attribute and a String and a method?
In Java, the size of a array of any object can be obtained with length, which would be an attribute. But in the case of String is length(), a method. However, if you have a array of String, Use length, an attribute. Why?
For example:
int[] a = {1,2};
String b = "str";
String[] c = {"aa", "bb"};
a.length;
b.length();
c.length;
3 answers
Arrays are treated differently from Strings, ArrayLists or anything else that can be counted in Java. A Array is pretty much a native type and its length cannot be changed after it is initialized, so there is no need for encapsulation. The length variable can be directly exposed without side effects.
The reason Strings uses a method instead of a variable is because it internally uses a char[]that it does not want to expose publicly (for immutability/encapsulation reasons), so it wraps the length variable in a length() method. It is the same reason as ArrayList to have a method size() instead of a variable length.
translated from What's the difference between length and length()?
Just remembering that a String itself is also immutable, and not only the array of char used internally by it, as can be confirmed in the documentation of the class
I went to research because I wanted to know why. It concludes that there is only speculation, no one knows the real reason. Only developers can answer this.
What seems clear to me is that the fact that the array is a language construct would be more appropriate to have a property than a phantom method that the language treats. Moreover, as this was one of the first things created in the language perhaps they did not think that a method could be better and more consistent.
String it is a common class and Java has no properties that only encapsulate access methods, i.e. it could only have the field exposed if it did not use a method. It would create compatibility issues between implementations, versions, and even become inconsistent with other frameworks that need the method, one case is the CharSequence. Even it is not so necessary since String is immutable, its value is not to change.
There are other theories, including those listed here, but they do not seem to me to make sense because even a public field could be placed its value whenever necessary. Perhaps they realized that there would be a new attribute taking up space that might or might not be needed.
I am not a fan of the term attribute that is even used in the language. It uses field for this .
Just to give more details to @user28595 answer.
As @Maniero noted in his comment, strings are immutable entities. In the other comments were placed more links on the subject of immutability. One of the aspects that makes this immutability important is a matter of optimization: substring operations in Java can be implemented very lightly (source). Depending on the Java implementation, a substring can be implemented as a continuous set of information from a character vector. From the example cited in the source, in jdk6 "abcde".substring(1,3) will generate a new object string , and this carries with it the same character vector {'a', 'b', 'c', 'd', 'e'} of the initial string , but it considers that it starts from the position 1 (b) and it goes right before the position 3, so it would be the position 2 (c). Not always a Java implementation ensures that a string has the vector size of characters that loads your data, possibly it could be that it loads only part of it. If it is the case of string storing the start and end index, the method length() returns fim - comeco; if it is implemented with offset of the first character and count, then the result of the method would be count (according to the example he gave of how it was in JDK6). If the implementation of string makes a copy of the desired subvector is used (as the example informs that they do in JDK7), then the length() method simply returns vetorDeChar.length.
An advantage of implementing string.length() as a method is that one can completely change the internal implementation (including existing fields) without the programmer using a string being affected. For smaller applications, the implementation strategies of string are not felt initially.
@Maniero talks about encapsulating of access properties that could solve this idiosyncrasy of Java
An interesting point about vectors is that access to their size is optimized by the JVM. There is a bytecode specialized in doing this: 0xBE, identified by the mnemonic arraylength. Using this specific bytecode has a lower generated result than what would be generated if the traditional bytecode were used.getfield (0xB4), which requires two more additional bytes for the attribute content. To Wikipedia has a page listing the bytecodes .