Java has a number of built-in scalar (in this context, nonobject) types. We discuss these below.

byte c;
int ival;
...
ival = ((int) c) && 0xFF; // explicit cast needed

if (strlen(instr)) {
 strcpy(buffer, instr);
}

int [] oned = new int[35];               // array = new type[size]
int alta [] = {1, 3, 5, 14, 11, 6, 24};  // alternative syntax plus
                                         // initialization
int j=0;

for(int i=0; i<35; i++) {
  oned[i] = valcomp(i, prop, alta[j]);   // array[index]
  if (++j > alta.length) {               // array.length
    j = 0;
  }
}

int [][] ragtag = new int[35][10];

for (int i=0; i<35; i++) {
  for (int j=0; j<10; j++) {
    ragtag[i][j] = i*j;
  } // next j
} // next i

int [][] ragtag = new int[17][];

for (int i=0; i<17; i++) {
  ragtag[i] = new int[10+i];
} // next i

for (int i=0; i<17; i++) {
  System.out.println("ragtag["+i+"] is "+ragtag[i].length+" long.");
} // next i

The real power in Java, or any object-oriented language, comes not from the scalar types, cool operators, or powerful control statements it provides (see below), but from its objects.

Object-oriented programming is a relatively recent innovation in software design and development. Objects are meant to embody the real world in a more natural way; they give us a way to describe, in our programs, the real-world objects with which we deal. If you are programming a business application, think of real-world business objects such as orders, customers, employees, addresses, and so on. Java is an object-oriented programming language and thus has some significant syntax related to OO concepts.

If you are new to object-oriented programming, be sure to read Chapter 1 of Eckel’s Thinking in Java.

In Java, we define a class to represent the objects about which we want to program. A class consists of the data and the methods to operate on that data. When we create a new instance of some class, that instance is an object of that type of class. Example 3.5 shows a simple class.

class
PairInt
{
  // data
  int i;
  int j;

  // constructors
  PairInt() { i=0; j=0; }
  PairInt(int ival, int jval) { i=ival; j=jval; }

  // methods
  setI(int val) { i=val; }
  setJ(int val) { j=val; }
  int getI() { return i; }
  int getJ() { return j; }
}

Note that this class defines both data (i, j) and methods (setI(), getJ(), and so on). We put all this into a file named PairInt.java to match the name of the class definition.

If some other Java code wanted to create and use a PairInt object, it would create it with the new keyword followed by a call to a constructor (Example 3.6).

This example shows only a snippet of code, not the entire PairInt class. That class, though, would likely reside in its own source file (named for its class name). In Java you normally create lots of files, one for each class. When it’s time to run the program, its various classes are loaded as needed. We’ll discuss grouping classes together and how Java locates them in Section 3.3.1.

// declare a reference to one:
PairInt twovals;

// now create one:
twovals = new PairInt(5, 4);

// we can also declare and create in one step:
PairInt twothers = new PairInt(7, 11);

In Java, each source file contains one class and the file is named after that class. It is possible to define inner classes located inside another class definition and thus inside its file, but that introduces other complexities that we wish to avoid discussing at this point. Most importantly, an inner class has access to even the private members of the enclosing class. (Read more about inner classes in any of the Java books that we recommend at the end of this chapter.)

For each of the class methods, class data declarations, and the class itself, Java has syntax to limit the scope, or visibility, of those pieces. The examples above didn’t include those keywords—that is, they took the default values. Usually you’ll want to specify something. See Section 3.4.1.

String strbystr = new String(oldstr);
String strbyarr = new String(myByteArray);

String xyz="this is the stringtext";

String phrase = "That is"
String fullsent = phrase + " all.";

Other Classes: Reading Javadoc

Java comes with a huge collection of existing classes for you to use. The simplest ones are just wrappers for the primitive classes. There is an int primitive data type, but Java provides an Integer class, so that you can have an integer as an object. Similarly, there are classes for Long, Float, Boolean, and so on. Such classes aren’t nearly as interesting as the myriad other classes that come with Java. These others provide objects for doing I/O, networking, 2D and 3D graphics, graphical user interfaces (GUIs), and distributed computing. Java provides ready-to-use classes for strings, math functions, and for special kinds of data structures like trees and sets and hash tables. There are classes to help you with the manipulation of HTML, XML, and SQL, as well as classes for sound, music, and video. All these objects can be yours to use and enjoy if you just learn the magic of reading Javadoc—online documentation for Java classes. The documentation for all these classes is viewed with a Web browser. (In a following chapter we’ll describe how you can make Javadoc documents for the classes that you write, too.)

The online version of the API documentation can be found at http://java.sun.com/j2se/1.4.2/docs/api/ for Java 1.4.2. (Similarly, put 1.5.1 or whatever version you want at the appropriate place in the URL.) When displayed, it shows a three-frame page, as seen in Figure 3.1, except that we’ve overlaid the image with three labels: A, B, and C.

Figure 3.1. The three frames of a Javadoc page

The upper left frame of the Javadoc display, the area labeled with A in our figure, lists all the packages that are part of Java 2 Standard Edition (J2SE). While there are many other packages of classes available for Java, these classes are the standard ones available without any other class libraries, with no additional downloads necessary. Other classes are documented in the same way—with Javadoc—but they are downloaded and displayed separately.

Frame B initially lists all the classes and interfaces available in all of the packages. When you select a package in A, B will display only those interfaces and classes that are part of the chosen package.

Frame C starts out with a list and description of all packages. Once you have selected a package in A, C will show the overview of that package, showing its classes and interfaces with descriptions.

But C is most often used to display the detailed description of a class. Choose a class or interface in B and you will see C filled with its description—some opening information followed by a list of the visible members of that class, followed by the possible constructors for that class and all the methods in that class (Figure 3.2). Each method is shown with its parameters and a one-sentence description. Clicking on the method name will open a fuller description (Figure 3.3).

Figure 3.2. Javadoc display of class information

Figure 3.3. Javadoc display of a single method

Since you will likely be referencing the Javadoc pages regularly, you may want to download a copy to your hard drive. From the same page on the java.sun.com Web site where you can download the Java SDK you can also download the API documentation.

If you agree to the licensing terms, you will download a large ZIP file. Installing the documentation, then, is just a matter of unzipping the file—but it’s best if you put it in a sensible location. If you have installed your Java SDK into a location like /usr/local/java then cd into that directory and unzip the file that you downloaded. Assuming that you saved the downloaded file into /tmp, a good place to put temporary files, and assuming that you have installed your version of Java into /usr/local/java and that you have write permission in that directory (check the permissions with ls -ld .) then you can run these commands:

$ cd /usr/local/java
$ unzip -q /tmp/j2sdk-1_4_2-doc.zip

There may be quite a pause (tens of seconds) while it unzips everything. The unzip command will spew out a huge list of filenames as it unpacks them unless you use the -q option (“quiet”) on the command line (which we did, to avoid all that). The files are all unzipped into a directory named docs. So now you can point your browser to

file:///usr/local/java/docs/api/index.html

Now you have your own local copy for quick reference, regardless of how busy the network or Sun’s Web site gets. Be sure to bookmark this page; you’ll want to reference it often. It’s your best source of information about all the standard Java2 classes.

This section is not intended to be a formal presentation of Java syntactic elements.^[3] Our purpose here is merely to show you the Java way to express common programming constructs. You will find that these are fundamentally similar to the analogous statements in C and C++. For much more detail on these subjects, see Chapter 3 of Thinking in Java by Bruce Eckel.

Like C, Java has a very small set of statements. Most constructs are actually expressions. Most operations are either assignments or method calls. Those few statements that are not expressions fall into two broad categories:

By the way, you may have already noticed one of the two kinds of comments that Java supports. They are like the C/C++ comments—a pair of slashes (//) marks a comment from there to the end of the line, and a block comment consists of everything from the opening /* to the closing */ sequence.

if (x < 0) {
    y = z + progo;
} else if (x > 5) {
    y = z + hmron;
    mylon.grebzob();
} else {
    y = z + engrom;
    mylon.kuggle();
}

switch (rval*k+zval)
{
  case 0:
    mylon.reset();
    break;
  case 1:
  case 4:
    // matches either 1 or 4
    y = zval+engrom;
    mylon.kuggle(y);
    break;
  default:
    // all other values end up here
    System.out.println("Unexpected value.");
    break;
}

while (greble != null)
{
  greble.glib();
  greble = treempl.morph();
}

do {

  greble.morph();
  xrof = treempl.glib();

} while (xrof == null);

for (i = 0; i < 8; i++) {
  System.out.println(i);
}

for ( before [, before]* ; exit_condition ; each_time [, each_time]* )
  statement

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

import java.util.*;

public class
Iter8
{
  public static void
  main(String [] args)
  {
    // create a new (empty) ArrayList
    ArrayList al = new ArrayList();

    // fill the ArrayList with args
    for(int i = 0; i < args.length; i++) {
      al.add(args[i]);
    }

    // use the iterator in the while loop
    Iterator itr1 = al.iterator();

    while(itr1.hasNext()) {
      String onearg;
      onearg = (String) (itr1.next());
      System.out.println("arg=" + onearg);
    }

    // define and use the iterator in the for loop:
    for(Iterator itr2 = al.iterator(); itr2.hasNext(); ) {
      String onearg;
      onearg = (String) (itr2.next());
      System.out.println("arg=" + onearg);
    }

  } // main

} // Iter8

import java.util.*;

public class
Foreign
{
  public static void
  main(String [] args)
  {
    List <String> loa = Arrays.asList(args);

    System.out.println("size=" + loa.size());

    for(String str : loa) {
      System.out.println("arg=" + str);
    }

  } // main
} // Foreign

for ( SomeType variable : SomeCollectionVariable ) {
}

import java.util.*;

public class
Forn
{
  public static void
  main(String [] args)
  {
    for(String str : args) {
      System.out.println("arg="+str);
    }

  } // main
} // Forn

Errors in Java are handled through exceptions. In some circumstances, the Java runtime will throw an exception, for example, when you reference a null pointer. Methods you write may also throw exceptions. This is quite similar to C++. But Java exceptions are classes. They descend from Object, and you can write your own classes that extend an existing exception. By so doing, you can carry up to the handler any information you would like. But we’re getting ahead of ourselves here. Let’s first describe the basics of exceptions, how to catch them, how to pass them along, and so forth.

In other programming languages a lot of code can be spent checking return codes of function or subroutine calls. If A calls B and B calls C and C calls D, then at each step the return value of the called function should be checked to see if the call succeeded. If not, something should be done about the error—though that “something” is usually just returning the error code to the next level up. So function C checks D’s return value, and if in error, returns an error code for B to check. B in turn looks for an error returned from C and returns an error code to A. In a sense, the error checking in B and C is superfluous. Its only purpose is to pass the error from its origin in D to the function that has some logic to deal with the error—in our example that’s A.

Java provides the try/catch/throw mechanism for more sophisticated error handling. It avoids a lot of unnecessary checking and passing on of errors. The only parts of a Java program that need to deal with an error are those that know what to do with it.

The throw in Java is really just a nonlocal “goto”—it will branch the execution of your program to a location which can be quite far away from the method where the exception was thrown. But it does so in a very structured and well-defined manner.

In our simple example of A calling B calling C calling D, D implemented as a Java method can throw an exception when it runs into an error. Control will pass to the first enclosing block of code on the call stack that contains a catch for that kind of exception. So A can have code that will catch an exception, and B and C need not have any error handling code at all. Example 3.17 demonstrates the syntax.

try {
  for (i = 0; i < max; i++) {
    someobj.methodB(param1, i);
  }
} catch (Exception e) {
  // do the error handling here:
  System.out.println("Error encountered. Try again.");
}
// continues execution here after successful completion
// but also after the catch if an error occurs

In the example, if any of the calls to methodB() in the for loop go awry—that is, anywhere inside methodB() or whatever methods it may call an exception is thrown (and assuming those called methods don’t have their own try/catch blocks), then control is passed up to the catch clause in our example. The for loop is exited unfinished, and execution continues first with the catch clause and then with the statements after the catch.

How does an error get thrown in the first place? One simply creates an Exception object and then throws the exception (Example 3.18).

Exception ex = new Exception("Bad News");
throw ex;

Since there is little point in keeping the reference to the object for the local method—execution is about to leave the local method—there is no need to declare a local variable to hold the exception. Instead, we can create the exception and throw it all in one step (Example 3.19).

throw new Exception("Bad News");

Exception is an object, and as such it can be extended. So we can create our own unique kinds of exceptions to differentiate all sorts of error conditions. Moreover, as objects, exceptions can contain any data that we might want to pass back to the calling methods to provide better diagnosis and recovery.

The try/catch block can catch different kinds of exceptions much like cases in a switch/case statement, though with different syntax (Example 3.20).

Notice that each catch has to declare the type of each exception and provide a local variable to hold a reference to that exception. Then method calls can be made on that exception or references to any of its publicly available data can be made.

Remember how we created an exception (new Exception("message"))? That message can be retrieved from the exception with the toString() method, as shown in that example. The method printStackTrace() is also available to print out the sequence of method calls that led up to the creation of the exception (Example 3.21).

The exception’s stack trace is read top to bottom showing the most recently called module first. Our example shows that the exception occurred (i.e., was constructed) on line 6 of the class named InnerMost, inside a method named doOtherStuff(). The doOtherStuff() method was called from inside the class MidModule—on line 7—in a method named doStuff(). In turn, doStuff() had been called by doSomething(), at line 11 inside AnotherClass, which itself had been called from line 14 in the ExceptExample class’ main() method.

try {
  for (i = 0; i < max; i++) {
    someobj.methodB(param1, i);
  } // next i

} catch (SpecialException sp) {
    System.out.println(sp.whatWentWrong());

} catch (AlternateException alt) {
    alt.attemptRepair(param1);

} catch (Exception e) {
    // do the error handling here:
    System.out.println(e.toString());
    e.printStackTrace();
}
// continues execution here after any catch

java.lang.Exception: Error in the fraberstam.
    at InnerMost.doOtherStuff(InnerMost.java:6)
    at MidModule.doStuff(MidModule.java:7)
    at AnotherClass.doSomething(AnotherClass.java:11)
    at ExceptExample.main(ExceptExample.java:14)

We want to mention one more piece of syntax for the try/catch block. Since execution may never get to all of the statements in a try block (the exception may make it jump out to a catch block), there is a need, sometimes, for some statements to be executed regardless of whether all the try code completed successfully. (One example might be the need to close an I/O connection.) For this we can add a finally clause after the last catch block. The code in the finally block will be executed (only once) after the try or after the catch—even if the path of execution is about to leave because of throwing an exception (Example 3.22).

try {
  for (i = 0; i < max; i++) {
    someobj.methodB(param1, i);
  } // next i

} catch (SpecialException sp) {
    System.out.println(sp.whatWentWrong());

} catch (AlternateException alt) {
    alt.attemptRepair(param1);
    throw alt;    // pass it on

} catch (Exception e) {
    // do the error handling here:
    System.out.println(e.toString());
    e.printStackTrace();

} finally {
    // Continue execution here after any catch
    // or after a try with no exceptions.
    // It will even execute after the AlternateException
    // before the throw takes execution away from here.
    gone = true;
    someobj = null;
}

We’ve already used println() in several examples, and assumed that you can figure out what it’s doing from the way we have used it. Without going whole-hog into an explanation of Java I/O and its various classes, we’d like to say a little more about the three various output methods on a PrintStream object.^[6]

Two of the methods, print() and println(), are almost identical. They differ only in that the latter one appends a newline (hence the ln) at the end of its output, thereby also flushing the output. They expect a String as their only argument, so when you want to output more than one thing, you add the Strings together, as in:

System.out.println("The answer is "+val);

“But what if val is not a String?” we hear you asking. Don’t worry, the Java compiler is smart enough to know, that when you are adding with a String argument it must convert the other argument to a String, too. So for any Object, it will implicitly call its toString() method. For any primitive type (e.g., int or boolean), the compiler will convert it to a String, too.

The third of the three output methods, printf(), sounds very familiar to C/C++ programmers, but be warned:

Perhaps the most significant enhancement to printf() is its additional syntax for dealing with internationalization. It’s all well and good to translate your Strings to a foreign language, but in doing so you may need to change the word order and thus the order of the arguments to printf(). For example, the French tend to put the adjective after rather than before the noun (as we do in English). We say “the red balloon” and they say “le balloon rouge.” If your program had Strings for adjective and noun, then a printf() like this:

String format = "the %s %s
";
System.out.printf(format, adjective, noun);

wouldn’t work if you translate just the format String:

String format = "le %s %s
";
System.out.printf(format, noun, adjective);

You’d like to be able to do the translation without changing the code in your program.^[8] With the Java version of printf(), there is syntax for specifying which argument corresponds to which format field in the format string. It uses a number followed by a dollar sign as part of the format field. This may be easier to explain by example; our French translation, switching the order in which the arguments are used, would be as follows:

String format = "le %2$s %1$s
";
System.out.printf(format, noun, adjective);

The format field %2$s says to use the second argument from the argument list—in this case, adjective—as the string that gets formatted here. Similarly, the format field %1$s says to use the first argument. In effect, the arguments get reversed without having to change the call to println(), only by translating the format String. Since such translations are often done in external files, rather than by assignment statements like we did for our example, it means that such external files can be translated without modifying the source to move arguments around.

This kind of argument specification can also be used to repeat an argument multiple times in a format string. This can be useful in formatting Date objects, where you use the same argument for each of the different pieces that make up a date—day, month, and so on. Each has its own format, but they can be combined by repeating the same argument for each piece. One format field formats the month, the next format field formats the day, and so on. Again an example may make it easier to see:

import java.util.Date;
Date today = new Date();
System.out.printf("%1$tm / %1$td / %1$ty
", today);

The previous statement uses the single argument, today, and formats it in three different ways, first giving the month, then the day of the month, then the year. The t format indicates a date/time format. There are several suffixes for it that specify parts of a date, a few of which are used in the example.^[9]

The details for all the different format fields can be found in the Javadoc for the java.util.Formatter class, a class that is used by printf() to do its formatting, but one that you can also use by itself (C programmers: think “sprintf”).

In order to implement printf() for Java, the language also had to be extended to allow for method calls with a varying number of arguments. So as of Java 5.0, a method’s argument list can be declared like this:

methodName(Type ... arglist)

This results in a method declaration which takes as its argument an array named arglist of values of type Type. That is, it is much the same as if you declared methodName(Type [] arglist) except that now the compiler will let you call the method with a varying number of arguments and it will load up the arguments into the array before calling the method. One other implication of this is that if you have a declaration like this:

varOut(String ... slist)

then you can’t, in the same class, also have one like this:

varOut(String [] alist)

because the former is just a compiler alias for the latter.

So how do you make a Java class part of a package? It’s easy—you just put, as the first (noncomment) line of the file, the package statement, naming the package to which you want this class to belong. So if you want your Account class to be part of the com.myco.financial package, your Java code would look as shown in Example 3.23.

package com.myco.financial;

public class
Account
{
  // ...
}

Making a class part of a package is easy. What’s tricky is putting the class file in the right location so that Java can find it.

Think of the current directory as the root of your package tree. Each part of a package name represents a directory from that point on down. So if you have a package named com.myco.financial then you’ll need a directory named com and within that a directory named myco and within that a directory named financial. Inside that financial directory you can put your Account.class file.

When Java runs a class file, it will look in all the directories named in the CLASSPATH environment variable. Check its current value:

$ echo $CLASSPATH

$

If it’s empty, as in this example, then the only place where it will look for your classes will be the current directory. That’s a handy default, because it is just what you want when your class file has no package statement in it. With no package statement, your class becomes part of the unnamed package. That’s fine for simple sample programs, but for serious application development you’ll want to use packages.

Let’s assume that you’re in your home directory, /home/joeuser, and beneath that you have a com directory and beneath that a myco directory with two subdirectories financial and util. Then with your classes in those lower level directories, you can run your Java program from the home directory. If you want to run it from any arbitrary directory (e.g., /tmp or /home/joeuser/alt) then you need to set CLASSPATH so it can find this package tree. Try:

$ export CLASSPATH="/home/joeuser"
$

Now Java knows where to look to find classes of the com.myco.financial and com.myco.util packages.

Once we have put our classes into packages, we have to use that package’s name when we refer to those classes—unless we use the import statement.

Continuing our example, if we want to declare a reference to an Account object, but Account is now part of com.myco.financial, then we could refer to it with its full name, as in:

com.myco.financial.Account =
    new com.myco.financial.Account(user, number);

which admittedly is a lot more cumbersome than just:

Account = new Account(user, number);

To avoid the unnecessarily long names, Java has import statements. They are put at the beginning of the class file, outside the class definition, just after any package statement. In an import statement, you can name a class with its full name, to avoid having to use the full name all the time. So our example becomes:

import com.myco.financial.Account;
// ...
Account = new Account(user, number);

If you have several classes from that package that you want to reference, you can name them all with a “*”, and you can have multiple different import statements, as in:

import java.util.*;
import com.myco.financial.*;
// ...
Account = new Account(user, number);

Here are a few things to remember about import statements. First, they don’t bring in any new code into the class. While their syntax and placement is reminiscent of the C/C++ include preprocessor directive, their function is not the same. An import statement does not include any new code; it only aids name resolution. Secondly, the “*” can only be used at the end of the package name; it is not a true wildcard in the regular expression sense of the word. Thirdly, every class has what is in effect an implicit import java.lang.* so that you don’t need to put one there. References to String or System or other core language classes can be made without the need for either the import statement or the fully qualified name (except as described in the next paragraph).

If you need to use two different classes that have the same name but come from different packages, you will still need to refer to them by their full names; import can’t help you here. As an example of this, consider the two classes java.util.Date and java.sql.Date (though with any luck you won’t need to refer to both of them within the same class).

Encapsulation is the grouping of data and algorithms together into units, and it’s also about hiding implementation details that are not important to the users of the unit. The basic unit of encapsulation is the class. All Java code exists in classes. A class is declared with the class keyword (Example 3.24).

public class
Sample
{
  private int id;

  public void method()
  {
    System.out.println(id);
  }
}

Inheritance is how a class places itself in a hierarchy of existing classes. In Java, each class inherits from exactly one existing class. A class names the class from which it inherits with the extends keyword. We said a Java class inherits from exactly one class, and yet our Example 3.24 doesn’t contain the extends keyword. What gives?

If a class doesn’t explicitly extend an existing class, it implicitly extends the “root” Java class, Object. The Object class has some interesting features, and the fact that all Java classes directly or indirectly extend Object has interesting consequences that we will explore later.

Persons coming to Java from another object-oriented language whose name shall remain C++ might wonder about multiple inheritance. Java has the concept of interfaces. An interface is like a class, except that it may not contain data^[10] and may contain only method definitions, without any implementation (Example 3.25). An interface may not be instantiated (created with the new operator),^[11] so how do you make use of interfaces? Well, a class extends exactly one existing base class, but it may implement any number of interfaces by using the implements keyword (Example 3.26).

public interface
Identifiable
{
  public int getID();
}

As you can see, a class that implements an interface must provide an implementation of all the methods defined in the interface. We said that an interface cannot be instantiated, but you can declare a variable of type Identifiable and assign an instance of the Sample class to it. In fact, you could assign an instance of any class that implements the Identifiable interface to it.

class
Sample
  implements Identifiable
{
  private int id;

  public void method()
  {
    System.out.println(id);
  }

  public int getID()
  {
    return id;
  }
}

Interfaces may also have an extends keyword. In other words, an interface may inherit from an existing interface. This may be useful if you know you will want to use methods from both the extended and the base interface without having to cast the object reference. Otherwise extending an interface is unnecessary since a given class may implement as many interfaces as desired.

private String hidn;
String pkgstr;
protected String protstr;
public String wideOpen;

import static java.lang.System.*;

public static void long lightSpeed = 186000;    // mps

enum WallMods { DOOR, WINDOW, VENT, GLASSBLOCK };

public MyClass
  extends BigClass
  implements Comparable, LotsaConstants
{
...
}

Polymorphism (from the Greek poly meaning “many” and morph meaning “shape”) refers to the language’s ability to deal with objects of many different “shapes,” that is, classes, as if they were all the same. We have already seen that Java does this via the extends and implements keywords. You can define an interface and then define two classes that both implement this interface.

Remember our Sample class (Example 3.26). We’ll now define another class, Employee, which also implements the Identifiable interface (Example 3.27).

class
Employee
  extends Person
  implements Identifiable
{
  private int empl_id;

  public int getID()
  {
    return empl_id;
  }
}

Notice that the same method, getID(), is implemented in the Employee class, but that the field from which it gets the ID value is a different field. That’s implementation-specific—the interface defines only the methods that can be called but not their internal implementation. The Employee class not only implements Identifiable, but it also extends the Person class, so we better show you what our example Person class looks like (Example 3.28).

To make a really useful Person class would take a lot more code than we need for our example. The important part for our example is only that it is quite different from the Sample class we saw earlier.

Example 3.29 demonstrates the use of polymorphism. We only show some small relevant snippets of code; there would be a lot more code for this to become an entire, complete example. Don’t be distracted by the constructors; we made up some new ones just for this example, that aren’t in the class definitions above. Can you see where the polymorphism is at work?

class
Person
{
  String name;
  Address addr;

  public
  Person(String name, Address addr)
  {
    this.name = name;
    this.addr = addr;

  } // constructor

  // ... lots more code is here

  public String getName()
  {
    return name;
  }
}

//...
Sample labwork = new Sample(petridish);
Employee tech = new Employee(newguy, 27);
Identifiable stuff;

//...
if (mode) {
    stuff = labwork;
} else {
    stuff = tech;
}
id = stuff.getID();

The key point here is when the call is made to getID(). The compiler can’t know at compile time which object will be referred to by stuff, so it doesn’t know whose getID() method will be called. But don’t worry—it works this all out at runtime. That’s polymorphism—Java can deal with these different objects while you, the programmer, can describe them in a generalized way.

One other related keyword should be mentioned here, abstract. When one declares a class as an abstract class, then the class itself is an incomplete definition. With an abstract class you define all the data of the class but need only write method declarations, not necessarily all the code for the methods. This makes abstract classes similar to interfaces, but in an abstract class, some of the methods can be fully written out.

If you’d like to know more about polymorphism, “late binding,” and more of this aspect of Java, read Chapter 7 of Eckel’s Thinking in Java. There is an extensive example there with much more detail than we can cover here.