4. The Java Language

4.1 Text Encoding

Java is a language for the Internet. Since the people of the Net speak and write in many different human languages, Java must be able to handle a number of languages as well. One of the ways in which Java supports international access is through Unicode character encoding. Unicode uses a 16-bit character encoding; it's a worldwide standard that supports the scripts (character sets) of most languages.[1]

[1] For more information about Unicode, see the following URL: http://www.unicode.org/. Ironically, one listed "obsolete and archaic" scripts not currently supported by the Unicode standard is Javanese--a historical language of the people of the Island of Java.

4.2 Comments

Java supports both C-style block comments delimited by /* and */ and C++-style line comments indicated by //:

/*  This is a 
        multiline 
            comment.    */ 
 
// This is a single line comment 
// and so // is this 

As in C, block comments can't be nested. Single-line comments are delimited by the end of a line; extra // indicators inside a single line have no effect. Line comments are useful for short comments within methods because you can still wrap block comments around large chunks of code during development.

By convention, a block comment beginning with /** indicates a special "doc comment." A doc comment is commentary that is extracted by automated documentation generators, such as Sun's javadoc program that comes with the Java Development Kit. A doc comment is terminated by the next */, just as with a regular block comment. Leading spacing up to a * on each line is ignored; lines beginning with @ are interpreted as special tags for the documentation generator:

/** 
 * I think this class is possibly the most amazing thing you will 
 * ever see. Let me tell you about my own personal vision and
 * motivation in creating it. 
 * <p> 
 * It all began when I was a small child, growing up on the 
 * streets of Idaho. Potatoes were the rage, and life was good... 
 * 
 * @see PotatoPeeler 
 * @see PotatoMasher 
 * @author John 'Spuds' Smith 
 * @version 1.00, 19 Dec 1996 
 */ 

javadoc creates HTML class documentation by reading the source code and the embedded comments. The author and version information is presented in the output and the @see tags make hypertext links to the appropriate class documentation. The compiler also looks at the doc comments; in particular, it is interested in the @deprecated tag, which means that the method has been declared obsolete and should be avoided in new programs. The compiler generates a warning message whenever it sees you use a deprecated feature in your code.

Doc comments can appear above class, method, and variable definitions, but some tags may not be applicable to all. For example, a variable declaration can contain only a @see tag. Table 4.1 summarizes the tags used in doc comments.

4.3 Types

The type system of a programming language describes how its data elements (variables and constants) are associated with actual storage. In a statically typed language, such as C or C++, the type of a data element is a simple, unchanging attribute that often corresponds directly to some underlying hardware phenomenon, like a register value or a pointer indirection. In a more dynamic language like Smalltalk or Lisp, variables can be assigned arbitrary elements and can effectively change their type throughout their lifetime. A considerable amount of overhead goes into validating what happens in these languages at run-time. Scripting languages like Tcl and awk achieve ease of use by providing drastically simplified type systems in which only certain data elements can be stored in variables, and values are unified into a common representation such as strings.

As I described in Chapter 1, Yet Another Language?, Java combines the best features of both statically and dynamically typed languages. As in a statically typed language, every variable and programming element in Java has a type that is known at compile-time, so the interpreter doesn't normally have to check the type validity of assignments while the code is executing. Unlike C or C++ though, Java also maintains run-time information about objects and uses this to allow safe run-time polymorphism.

Java data types fall into two categories. Primitive types represent simple values that have built-in functionality in the language; they are fixed elements like literal constants and numeric expressions. Reference types (or class types) include objects and arrays; they are called reference types because they are passed "by reference" as I'll explain shortly.

int foo; 
double d1, d2; 
boolean isFun; 

int foo = 42; 
double d1 = 3.14, d2 = 2 * 3.14; 
boolean isFun = true; 

int i = 1230; 

int i = 01230;             // i = 664 decimal 

int i = 0xFFFF;            // i = 65535 decimal 

long l = 13L; 
long l = 13;               // equivalent--13 is converted from type int 

int i = 13; 
byte b = i;                // Compile time error--explicit cast needed 
byte b = (byte) i;         // Okay 

double d = 8.31; 
double e = 3.00e+8; 
float f = 8.31F; 
float g = 3.00e+8F; 

char a = 'a'; 
char newline = '\n'; 
char octalff = \u00ff; 

Foo myFoo = new Foo(); 
Foo anotherFoo = myFoo; 

// C++ 
Foo& myFoo = *(new Foo()); 
Foo& anotherFoo = myFoo; 

myMethod( myFoo ); 

System.out.println( "Hello World..." ); 
String s = "I am the walrus..."; 
String t = "John said: \"I am the walrus...\""; 

String quote = "Four score and " + "seven years ago,"; 
String more = quote + " our" + " fathers" +  " brought..."; 

4.4 Statements and Expressions

Although the method declaration syntax of Java is quite different from that of C++, Java statement and expression syntax is very much like that of C. Again, the design intention was to make the low-level details of Java easily accessible to C programmers, so that they can concentrate on learning the parts of the language that are really different. Java statements appear inside of methods and class and variable initializers; they describe all activities of a Java program. Variable declarations and initializations like those in the previous section are statements, as are the basic language structures like conditionals and loops. Expressions are statements that produce a result that can be used as part of another statement. Method calls, object allocations, and, of course, mathematical expressions are examples of expressions.

One of the tenets of Java is to keep things simple and consistent. To that end, when there are no other constraints, evaluations and initializations in Java always occur in the order in which they appear in the code--from left to right. We'll see this rule used in the evaluation of assignment expressions, method calls, and array indexes, to name a few cases. In some other languages, the order of evaluation is more complicated or even implementation dependent. Java removes this element of danger by precisely and simply defining how the code is evaluated. This doesn't, however, mean you should start writing obscure and convoluted statements. Relying on the order of evaluation of expressions is a bad programming habit, even when it works. It produces code that is hard to read and harder to modify. Real programmers, however, are not made of stone, and you may catch me doing this once or twice when I can't resist the urge to write terse code.

{ 
    int size = 5; 
    setName("Max"); 
    ... 
} 

setupDog( String name ) { 
    int size = 5; 
    setName( name ); 
    ... 
} 

{ 
    int i = 5; 
} 
 
i = 6;           // compile time error, no such variable i 

if ( condition ) 
    statement; 
[ else 
    statement; ] 

if ( condition ) 
    statement; 

if ( condition )  { 
    [ statement; ] 
    [ statement; ] 
    [ ... ] 
} 

while ( conditional ) 
    statement; 
 
do 
    statement; 
while ( conditional ); 

for ( initialization; conditional; incrementor ) 
    statement; 

for (int i = 0; i < 100; i++ ) { 
    System.out.println( i ) 
    int j = i; 
    ... 
} 

for (int i = 0, j = 10; i < j; i++, j-- ) { 
   ... } 

switch ( int expression ) { 
    case int expression : 
        statement; 
    [ case int expression 
        statement; 
    ... 
    default : 
        statement;  ] 
} 

No two of the case expressions can evaluate to the same value. As in C, an optional default case can be specified to catch unmatched conditions. Normally, the special statement break is used to terminate a branch of the switch:

switch ( retVal ) { 
    case myClass.GOOD : 
        // something good 
        break; 
    case myClass.BAD : 
        // something bad 
        break; 
    default :
        // neither one 
        break; 
} 

The Java break statement and its friend continue perform unconditional jumps out of a loop or conditional statement. They differ from the corresponding statements in C by taking an optional label as an argument. Enclosing statements, like code blocks and iterators, can be labeled with identifier statements:

one: 
    while ( condition ) { 
        ... 
        two: 
            while ( condition ) { 
                ... 
                // break or continue point 
            } 
        // after two 
    } 
// after one 

In the above example, a break or continue without argument at the indicated position would have the normal, C-style effect. A break would cause processing to resume at the point labeled "after two"; a continue would immediately cause the two loop to return to its condition test.

The statement break two at the indicated point would have the same effect as an ordinary break, but break one would break two levels and resume at the point labeled "after one." Similarly, continue two would serve as a normal continue, but continue one would return to the test of the one loop. Multilevel break and continue statements remove much of the need for the evil goto statement in C and C++.

There are a few Java statements we aren't going to discuss right now. The try, catch, and finally statements are used in exception handling, as we'll discuss later in this chapter. The synchronized statement in Java is used to coordinate access to statements among multiple threads of execution; see Chapter 6, Threads for a discussion of thread synchronization.

On a final note, I should mention that the Java compiler flags "unreachable" statements as compile-time errors. Of course, when I say unreachable, I mean those statements the compiler determines won't be called by a static look at compile-time.

Expressions

As I said earlier, expressions are statements that produce a result when they are evaluated. The value of an expression can be a numeric type, as in an arithmetic expression; a reference type, as in an object allocation; or the special type void, which results from a call to a method that doesn't return a value. In the last case, the expression is evaluated only for its side effects (i.e., the work it does aside from producing a value). The type of an expression is known at compile-time. The value produced at run-time is either of this type or, in the case of a reference type, a compatible (assignable) type.

int i, j; 
i = 5;                           // expression 

j = ( i = 5 ); 

int i; 
String s; 
i = myObject.length; 
s = myObject.name; 

int len = myObject.name.length(); 
int initialLen = myObject.name.substring(5, 10).length(); 

System.out.println( "Hello World..." ); 
int myLength = myString.length();  

Object o = new Object(); 

int hours = new Date().getHours(); 

Boolean b; 
String str = "foo"; 
b = ( str instanceof String );     // true 
b = ( str instanceof Object );     // also true 
b = ( str instanceof Date );       // false--not a Date or subclass 

        if ( foo instanceof byte[] )
            ...

String s = null;
if ( s istanceof String )
    // won't happen

4.5 Exceptions

Do, or do not... There is no try.

--Yoda (The Empire Strikes Back)

Exceptions and Error Classes

Exceptions are represented by instances of the class java.lang.Exception and its subclasses. Subclasses of Exception can hold specialized information (and possibly behavior) for different kinds of exceptional conditions. However, more often they are simply "logical" subclasses that exist only to serve as a new exception type (more on that later). Figure 4.1 shows the subclasses of Exception; these classes are defined in various packages in the Java API, as indicated in the diagram.

An Exception object is created by the code at the point where the error condition arises. It can hold whatever information is necessary to describe the exceptional condition, including a full stack trace for debugging. The exception object is passed, along with the flow of control, to the handling block of code. This is where the terms "throw" and "catch" come from: the Exception object is thrown from one point in the code and caught by the other, where execution resumes.

The Java API also defines the java.lang.Error class for eggregious or unrecoverable errors. The subclasses of Error are shown in Figure 4.2. You needn't worry about these errors (i.e., you do not have to catch them); they normally indicate linkage problems or virtual machine errors. An error of this kind usually causes the Java interpreter to display a message and exit.

Exception Handling

The try/catch guarding statements wrap a block of code and catch designated types of exceptions that occur within it:

try { 
    readFromFile("foo"); 
    ... 
}  
catch ( Exception e ) { 
    // Handle error 
    System.out.println( "Exception while reading file: " + e ); 
    ... 
} 

In the above example, exceptions that occur within the body of the try statement are directed to the catch clause for possible handling. The catch clause acts like a method; it specifies an argument of the type of exception it wants to handle, and, if it's invoked, the Exception object is passed into its body as an argument. Here we receive the object in the variable e and print it along with a message.

A try statement can have multiple catch clauses that specify different specific types (subclasses) of Exception:

try { 
    readFromFile("foo"); 
    ... 
}  
catch ( FileNotFoundException e ) { 
    // Handle file not found 
    ... 
}  
catch ( IOException e ) { 
    // Handle read error 
    ... 
}  
catch ( Exception e ) { 
    // Handle all other errors 
    ... 
} 

The catch clauses are evaluated in order, and the first possible (assignable) match is taken. At most one catch clause is executed, which means that the exceptions should be listed from most specific to least. In the above example, we'll assume that the hypothetical readFromFile() can throw two different kinds of exceptions: one that indicates the file is not found; the other indicates a more general read error. Any subclass of Exception is assignable to the parent type Exception, so the third catch clause acts like the default clause in a switch statement and handles any remaining possibilities.

It should be obvious, but one beauty of the try/catch statement is that any statement in the try block can assume that all previous statements in the block succeeded. A problem won't arise suddenly because a programmer forgot to check the return value from some method. If an earlier statement fails, execution jumps immediately to the catch clause; later statements are never executed.

Bubbling Up

What if we hadn't caught the exception? Where would it have gone? Well, if there is no enclosing try/catch statement, the exception pops to the top of the method in which it appeared and is, in turn, thrown from that method. In this way, the exception bubbles up until it's caught, or until it pops out of the top of the program, terminating it with a run-time error message. There's a bit more to it than that because, in this case, the compiler would have reminded us to deal with it, but we'll get back to that in a moment.

Let's look at another example. In Figure 4.3, the method getContent() invokes the method openConnection() from within a try/catch statement. openConnection(), in turn, invokes the method sendRequest(), which calls the method write() to send some data.

In this figure, the second call to write() throws an IOException. Since sendRequest() doesn't contain a try/catch statement to handle the exception, it's thrown again, from the point that it was called in the method openConnection(). Since openConnection() doesn't catch the exception either, it's thrown once more. Finally it's caught by the try statement in getContent() and handled by its catch clause.

Since an exception can bubble up quite a distance before it is caught and handled, we may need a way to determine exactly where it was thrown. All exceptions can dump a stack trace that lists their method of origin and all of the nested method calls that it took to arrive there, using the printStackTrace() method.

try {
    // complex task
} catch ( Exception e ) {
    // dump information about exactly where the exception ocurred
    e.printStackTrack( System.err );
    ...
}

The throws Clause and checked Exceptions

I mentioned earlier that Java makes us be explicit about our error handling. But Java is programmer-friendly, and it's not possible to require that every conceivable type of error be handled in every situation. So, Java exceptions are divided into two categories: checked exceptions and unchecked exceptions. Most application level exceptions are checked, which means that any method that throws one, either by generating it itself (as we'll discuss below) or by passively ignoring one that occurs within it, must declare that it can throw that type of exception in a special throws clause in its method declaration. We haven't yet talked in detail about declaring methods; we'll cover that in Chapter 5, Objects in Java. For now all you need know is that methods have to declare the checked exceptions they can throw or allow to be thrown.

Again in Figure 4.3, notice that the methods openConnection() and sendRequest() both specify that they can throw an IOException. If we had to throw multiple types of exceptions we could declare them separated with commas:

void readFile( String s ) throws IOException, InterruptedException { 
    ... 
} 

The throws clause tells the compiler that a method is a possible source of that type of checked exception and that anyone calling that method must be prepared to deal with it. The caller may use a try/catch block to catch it, or it may, itself, declare that it can throw the exception.

Exceptions that are subclasses of the java.lang.RuntimeException class are unchecked. See Figure 4.1 for the subclasses of RuntimeException. It's not a compile-time error to ignore the possibility of these exceptions being thrown; additionally, methods don't have to declare they can throw them. In all other respects, run-time exceptions behave the same as other exceptions. We are perfectly free to catch them if we wish; we simply aren't required to.

Checked exceptions

Exceptions a reasonable application should try to handle gracefully.

Unchecked exception (Runtime exceptions)

Exceptions from which we would not normally expect our software to try to recover.

The category of checked exceptions includes application-level problems like missing files and unavailable hosts. As good programmers (and upstanding citizens), we should design software to recover gracefully from these kinds of conditions. The category of unchecked exceptions includes problems such as "out of memory" and "array index out of bounds." While these may indicate application-level programming errors, they can occur almost anywhere and aren't generally easy to recover from. Fortunately, because there are unchecked exceptions, you don't have to wrap every one of your array-index operations in a try/catch statement.

Throwing Exceptions

We can throw our own exceptions: either instances of Exception or one of its predefined subclasses, or our own specialized subclasses. All we have to do is create an instance of the Exception and throw it with the throw statement:

throw new Exception(); 

Execution stops and is transferred to the nearest enclosing try/catch statement. (Note that there is little point in keeping a reference to the Exception object we've created here.) An alternative constructor of the Exception class lets us specify a string with an error message:

throw new Exception("Something really bad happened");

By convention, all types of Exception have a String constructor like this. Note that the String message above is somewhat facetious and vague. Normally you won't be throwing a plain old Exception, but a more specific subclass. For example:

public void checkRead( String s ) {  
    if ( new File(s).isAbsolute() || (s.indexOf("..") != -1) ) 
        throw new SecurityException(
           x"Access to file : "+ s +" denied."); 
} 

In the above, we partially implement a method to check for an illegal path. If we find one, we throw a SecurityException, with some information about the transgression.

Of course, we could include whatever other information is useful in our own specialized subclasses of Exception (or SecurityException). Often though, just having a new type of exception is good enough, because it's sufficient to help direct the flow of control. For example, if we are building a parser, we might want to make our own kind of exception to indicate a particular kind of failure.

class ParseException extends Exception {
    ParseException() { 
        super(); }
    ParseException( String desc ) { 
        super( desc ) };
}

See Chapter 5, Objects in Java for a full description of classes and class constructors. The body of our exception class here simply allows a ParseException to be created in the conventional ways that we have created exceptions above. Now that we have our new exception type, we we might guard for it in the following kind of situation:

// Somewhere in our code
...
try {
    parseStream( input );
} catch ( ParseException pe ) {
    // Bad input...
} catch ( IOException ioe ) {
    // Low level communications problem
}

As you can see, although our new exception doesn't currently hold any specialized information about the problem (it certainly could), it does let us distinguish a parse error from an arbitrary communications error in the same chunk of code. You might call this kind of specialization of an exception to be making a "logical" exception.

  *** I was going to say something about fillInStackTrack() here ***

Try Creep

The try statement imposes a condition on the statements they guard. It says that if an exception occurs within it, the remaining statements will be abandoned. This has consequences for local variable initialization. If the compiler can't determine whether a local variable assignment we placed inside a try/catch block will happen, it won't let us use the variable:

void myMethod() { 
    int foo; 
 
    try { 
        foo = getResults(); 
    }  
    catch ( Exception e ) { 
        ... 
    } 
 
    int bar = foo;  // Compile time error--foo may not 
                    // have been initialized 

In the above example, we can't use foo in the indicated place because there's a chance it was never assigned a value. One obvious option is to move the assignment inside the try statement:

try { 
    foo = getResults(); 
    int bar = foo;  // Okay because we only get here 
                    // if previous assignment succeeds 
}  
catch ( Exception e ) { 
    ... 
} 

Sometimes this works just fine. However, now we have the same problem if we want to use bar later in myMethod(). If we're not careful, we might end up pulling everything into the try statement. The situation changes if we transfer control out of the method in the catch clause:

try { 
    foo = getResults(); 
}  
catch ( Exception e ) { 
    ... 
    return; 
} 
 
int bar = foo;  // Okay because we only get here 
                // if previous assignment succeeds 

Your code will dictate its own needs; you should just be aware of the options.

The finally Clause

What if we have some clean up to do before we exit our method from one of the catch clauses? To avoid duplicating the code in each catch branch and to make the cleanup more explicit, Java supplies the finally clause. A finally clause can be added after a try and any associated catch clauses. Any statements in the body of the finally clause are guaranteed to be executed, no matter why control leaves the try body:

try { 
    // Do something here 
}  
catch ( FileNotFoundException e ) { 
    ... 
}  
catch ( IOException e ) { 
    ... 
}  
catch ( Exception e ) { 
    ... 
}  
finally { 
    // Cleanup here 
} 

In the above example the statements at the cleanup point will be executed eventually, no matter how control leaves the try. If control transfers to one of the catch clauses, the statements in finally are executed after the catch completes. If none of the catch clauses handles the exception, the finally statements are executed before the exception propagates to the next level.

If the statements in the try execute cleanly, or even if we perform a return, break, or continue, the statements in the finally clause are executed. To perform cleanup operations, we can even use try and finally without any catch clauses:

try { 
    // Do something here 
    return; 
}  
finally { 
    System.out.println("Whoo-hoo!"); 
} 

Exceptions that occur in a catch or finally clause are handled normally; the search for an enclosing try/catch begins outside the offending try statement.

4.6 Arrays

An array is a special type of object that can hold an ordered collection of elements. The type of the elements of the array is called the base type of the array; the number of elements it holds is a fixed attribute called its length. (For a collection with a variable length, see the discussion of Vector objects in Chapter 7, Basic Utility Classes.) Java supports arrays of all numeric and reference types.

The basic syntax of arrays looks much like that of C or C++. We create an array of a specified length and access the elements with the special index operator, []. Unlike other languages, however, arrays in Java are true, first-class objects, which means they are real objects within the Java language. An array is an instance of a special Java array class and has a corresponding type in the type system. This means that to use an array, as with any other object, we first declare a variable of the appropriate type and then use the new operator to create an instance of it.

Array objects differ from other objects in Java in three respects:

• Java implicitly creates a special array class for us whenever we declare an array type variable. It's not strictly necessary to know about this process in order to use arrays, but it helps in understanding their structure and their relationship to other objects in Java.
• Java lets us use the special [] operator to access array elements, so that arrays look as we expect. We could implement our own classes that act like arrays, but because Java doesn't have user-defined operator overloading, we would have to settle for having methods like get() and put() instead of using the special [] notation.
• Java provides a corresponding special form of the new operator that lets us construct an instance of an array and specify its length with the [] notation.

int [] arrayOfInts; 
int arrayOfInts []; 

String [] someStrings; 
Button someButtons []; 

arrayOfInts = new int [42]; 
someStrings = new String [ number + 2 ]; 

double [] someNumbers = new double [20]; 
Component widgets [] = new Component [12]; 

int [] grades = new int [30]; 
grades[0] = 99; 
grades[1] = 72; 
// grades[2] == 0 

String names [] = new String [4]; 
names [0] = new String(); 
names [1] = "Boofa"; 
names [2] = someObject.toString(); 
// names[3] == null 

names is a variable of type String[] (i.e., a string array). The String[] object can be thought of as containing four String type variables. We have assigned String objects to the first three array elements. The fourth has the default value null.

Java supports the C-style curly braces {} construct for creating an array and initializing its elements when it is declared:

int [] primes = { 1, 2, 3, 5, 7, 7+4 };    // primes[2] == 3 

An array object of the proper type and length is implicitly created and the values of the comma-separated list of expressions are assigned to its elements.

We can use the {} syntax with an array of objects. In this case, each of the expressions must evaluate to an object that can be assigned to a variable of the base type of the array, or the value null. Here are some examples:

String [] verbs = { "run", "jump", someWord.toString() }; 
Button [] controls = { stopButton, new Button("Forwards"),  
    new Button("Backwards") }; 
// all types are subtypes of Object 
Object [] objects = { stopButton, "A word", null }; 

You should create and initialize arrays in whatever manner is appropriate for your application. The following are equivalent:

Button [] threeButtons = new Button [3]; 
Button [] threeButtons = { null, null, null }; 

Using Arrays

The size of an array object is available in the public variable length:

char [] alphabet = new char [26]; 
int alphaLen = alphabet.length;             // alphaLen == 26 
 
String [] musketeers = { "one", "two", "three" }; 
int num = musketeers.length;                // num == 3 

length is the only accessible field of an array; it is a variable, not a method.

Array access in Java is just like array access in C; you access an element by putting an integer-valued expression between brackets after the name of the array. The following example creates an array of Button objects called keyPad and then fills the array with Button objects:

Button [] keyPad = new Button [ 10 ]; 
for ( int i=0; i < keyPad.length; i++ )      keyPad[ i ] = new Button( Integer.toString( i ) );

Attempting to access an element that is outside the range of the array generates an ArrayIndexOutOfBoundsException. This is a type of RuntimeException, so you can either catch it and handle it yourself, or ignore it, as we already discussed:

String [] states = new String [50]; 
 
try { 
    states[0] = "California"; 
    states[1] = "Oregon"; 
    ... 
    states[50] = "McDonald's Land";  // Error--array out of bounds 
}  
catch ( ArrayIndexOutOfBoundsException err ) { 
    System.out.println( "Handled error: " + err.getMessage() ); 
} 

It's a common task to copy a range of elements from one array into another. Java supplies the arraycopy() method for this purpose; it's a utility method of the System class:

System.arraycopy( source, sourceStart, destination, 
                  destStart, length ); 

The following example doubles the size of the names array from an earlier example:

String [] tmpVar = new String [ 2 * names.length ]; 
System.arraycopy( names, 0, tmpVar, 0, names.length ); 
names = tmpVar; 

A new array, twice the size of names, is allocated and assigned to a temporary variable tmpVar. arraycopy() is used to copy the elements of names to the new array. Finally, the new array is assigned to names. If there are no remaining references to the old array object after names has been copied, it will be garbage collected on the next pass.

Anonymous Arrays

You often want to create "throw-away" arrays: arrays that are only used in one place, and never referenced anywhere else. Such arrays don't need to have a name, because you never need to refer to them again in that context. For example, you may want to create a collection of objects to pass as an argument to some method. It's easy enough to create a normal, named array--but if you don't actually work with the array (if you use the array only as a holder for some collection), you shouldn't have to. Java makes it easy to create "anonymous" (i.e., unnamed) arrays.

Let's say you need to call a method named setPets(), which takes an array of Animal objects as arguments. Cat and Dog are subclasses of Animal. Here's how to call setPets() using an anonymous array:

Dog pokey = new Dog ("gray");
Cat squiggles = new Cat ("black");
Cat jasmine = new Cat ("orange");
setPets ( new Animal [] { pokey, squiggles, jasmine });

The syntax looks just like the initialization of an array in a variable declaration. We implicitly define the size of the array and fill in its elements using the curly brace notation. However, since this is not a variable declaration we have to explicitly use the new operator to create the array object.

You can use anonymous arrays to simulate variable length argument lists (often called VARARGS), a feature of many programming languages that Java doesn't provide. The advantage of anonymous arrays over variable length argument lists is that it allows stricter type checking; the compiler always knows exactly what arguments are expected, and therefore can verify that method calls are correct.

Multidimensional Arrays

Java supports multidimensional arrays in the form of arrays of array type objects. You create a multidimensional array with C-like syntax, using multiple bracket pairs, one for each dimension. You also use this syntax to access elements at various positions within the array. Here's an example of a multidimensional array that represents a chess board:

ChessPiece [][] chessBoard; 
chessBoard = new ChessPiece [8][8]; 
chessBoard[0][0] = new ChessPiece( "Rook" ); 
chessBoard[1][0] = new ChessPiece( "Pawn" ); 
... 

Here chessBoard is declared as a variable of type ChessPiece[][] (i.e., an array of ChessPiece arrays). This declaration implicitly creates the type ChessPiece[] as well. The example illustrates the special form of the new operator used to create a multidimensional array. It creates an array of ChessPiece[] objects and then, in turn, creates each array of ChessPiece objects. We then index chessBoard to specify values for particular ChessPiece elements. (We'll neglect the color of the pieces here.)

Of course, you can create arrays of with more than two dimensions. Here's a slightly impractical example:

Color [][][] rgbCube = new Color [256][256][256]; 
rgbCube[0][0][0] = Color.black; 
rgbCube[255][255][0] = Color.yellow; 
... 

As in C, we can specify the initial index of a multidimensional array to get an array type object with fewer dimensions. In our example, the variable chessBoard is of type ChessPiece[][]. The expression chessBoard[0] is valid and refers to the first element of chessBoard, which is of type ChessPiece[]. For example, we can create a row for our chess board:

ChessPiece [] startRow =  { 
    new ChessPiece("Rook"), new ChessPiece("Knight"), 
    new ChessPiece("Bishop"), new ChessPiece("King"), 
    new ChessPiece("Queen"), new ChessPiece("Bishop"), 
    new ChessPiece("Knight"), new ChessPiece("Rook") 
}; 
 
chessBoard[0] = startRow; 

We don't necessarily have to specify the dimension sizes of a multidimensional array with a single new operation. The syntax of the new operator lets us leave the sizes of some dimensions unspecified. The size of at least the first dimension (the most significant dimension of the array) has to be specified, but the sizes of any number of the less significant array dimensions may be left undefined. We can assign appropriate array type values later.

We can create a checkerboard of boolean values (which is not quite sufficient for a real game of checkers) using this technique:

boolean [][] checkerBoard; 
checkerBoard = new boolean [8][]; 

Here, checkerBoard is declared and created, but its elements, the eight boolean[] objects of the next level, are left empty. Thus, for example, checkerBoard[0] is null until we explicitly create an array and assign it, as follows:

checkerBoard[0] = new boolean [8]; 
checkerBoard[1] = new boolean [8]; 
... 
checkerBoard[7] = new boolean [8]; 

The code of the previous two examples is equivalent to:

boolean [][] checkerBoard = new boolean [8][8]; 

One reason we might want to leave dimensions of an array unspecified is so that we can store arrays given to us by another method.

Note that since the length of the array is not part of its type, the arrays in the checkerboard do not necessarily have to be of the same length. Here's a defective (but perfectly legal) checkerboard:

checkerBoard[2] = new boolean [3]; 
checkerBoard[3] = new boolean [10]; 

Since Java implements multidimensional arrays as arrays of arrays, multidimensional arrays do not have to be rectangular. For example, here's how you could create and initialize a triangular array:

int []][] triangle = new int [5][]; 
for (int i = 0; i < triangle.length; i++) {  
    triangle[i] = new int [i + 1]; 
    for (int j = 0; j < i + 1; j++) 
        triangle[i][j] = i + j;    } 

Inside Arrays

I said earlier that arrays are instances of special array classes in the Java language. If arrays have classes, where do they fit into the class hierarchy and how are they related? These are good questions; however, we need to talk more about the object-oriented aspects of Java before I can answer them. For now, take it on faith that arrays fit into the class hierarchy; details are in Chapter 5, Objects in Java.