Java Data Types: String and Array

Question

I've been going through Sun Microsystem's Java Tutorial and got some questions while reading the following:

I/O from the Command Line: The Console Object

"Second, readPassword returns a character array, not a String, so the password can be
 overwritten, removing it from memory as soon as it is no longer needed."

My questions are:

1) With regard to other data types, such as value data types(int, float, boolean etc), and reference types(user-defined objects, etc), how are arrays and Strings in Java different?

2) Can you elaborate on the above statement about character array and String?

P.S:

Clarification to Q1: What I wanted to ask on Q1 was more about what arrays and Strings are as data-types in Java... With their object-like attributes, I get easily confused when someone claims that Strings and Arrays are not objects in a strict sense...

Answer 1

At a practical level, the main difference between String and char[] is that the instances of the former are immutable, and instances of the latter are mutable. And of course, the String API offers a wide range of useful methods string manipulation methods.

So lets talk about the linguistic similarities and differences.

First and foremost, (notwithstanding what you may have heard) strings and array instances in Java are both objects. According to the Java Language Specification:

4.3.1 Objects An object is a class instance or an array.

The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object.

... where the class of a string is java.lang.String.

The linguistic distinction between arrays and other object types is that the type of an array is not a normal Java class. For example:

• Array types are declared with a different syntax to normal classes.
• Array instances are created with a different syntax to normal class instances.
• Array types cannot be named at the Java source code level.
• You cannot declare a subtype / subclass of an array type.

But all array types are (direct) subtypes of java.lang.Object, which means that you can (for example) assign an array to a variable of type Object, and invoke methods in the Object API. (And there are some interesting things that you can do with these methods to demonstrate the "object-ness" of an array ... but I digress)

So what about strings? As mentioned above, a "string" is a normal object which is an instance of the class java.lang.String. There is nothing unusual about this class from a linguistic perspective. It is declared as "final" so that you cannot declare subtypes, but that is not unusual.

The thing that makes String a bit special compared with other classes is that the Java language provides some linguistic constructs to support strings:

• There is a special String literal syntax for obtaining strings whose content can be determined at compile time.
• The '+' operator is overloaded to support String concatenation.
• From Java 7 onwards, the switch statement supports switching on String values.
• The Java Language Specification defines/assumes that the java.lang.String class has certain properties and methods; e.g. that strings are mutable, that there is a concat method, that string literals are "interned".

By the way, the answer that said that all string instances are held in a string pool is incorrect. Strings are only put in the pool when they interned, and this only happens automatically for string literals and for strings whose values can be calculated at compile-time. (You can force a string instance to be interned by calling the String.intern() method, but this is bit expensive, and not generally a good idea.)

Answer 2

A String stores its contents internally as an array of chars. You cannot manipulate this array directly (without reflection), since Strings are immutable.

The reason the password would be in a char[] is so that you can immediately overwrite it in memory. If it were in a String, you would have to wait for the next garbage collection, and you never know how long that's going to be; an attacker could potentially read it out of memory before then.