Index

<< Resources:Software, Books, My own list of books

class MyJavaClass {

public int aValue;

public void divByTwo() { aValue /= 2; }

}

public class UseObjects {

private native void

changeObject(MyJavaClass obj);

static {

System.loadLibrary("UseObjImpl");

// Linux hack, if you can't get your library

// path set in your environment:

// System.load(

//"/home/bruce/tij2/appendixb/UseObjImpl.so");

}

public static void main(String[] args) {

UseObjects app = new UseObjects();

MyJavaClass anObj = new MyJavaClass();

anObj.aValue = 2;

app.changeObject(anObj);

System.out.println("Java: " + anObj.aValue);

}

} ///:~

After compiling the code and running javah, you can implement the

native method. In the example below, once the field and method ID are

obtained, they are accessed through JNI functions.

//: appendixb:UseObjImpl.cpp

//# Tested with VC++ & BC++. Include path must

//# be adjusted to find the JNI headers. See

//# the makefile for this chapter (in the

//# downloadable source code) for an example.

#include <jni.h>

extern "C" JNIEXPORT void JNICALL

Java_UseObjects_changeObject(

JNIEnv* env, jobject, jobject obj) {

jclass cls = env->GetObjectClass(obj);

jfieldID fid = env->GetFieldID(

cls, "aValue", "I");

jmethodID mid = env->GetMethodID(

1072

Thinking in Java

cls, "divByTwo", "()V");

int value = env->GetIntField(obj, fid);

printf("Native: %d\n", value);

env->SetIntField(obj, fid, 6);

env->CallVoidMethod(obj, mid);

value = env->GetIntField(obj, fid);

printf("Native: %d\n", value);

} ///:~

Ignoring the "this" equivalent, the C++ function receives a jobject, which

is the native side of the Java object reference we pass from the Java code.

We simply read aValue, print it out, change the value, call the object's

divByTwo( ) method, and print the value out again.

To access a Java field or method, you must first obtain its identifier using

GetFieldID( ) for fields and GetMethodID( ) for methods. These

functions take the class object, a string containing the element name, and

a string that gives type information: the data type of the field, or signature

information for a method (details can be found in the JNI

documentation). These functions return an identifier that you use to

access the element. This approach might seem convoluted, but your native

method has no knowledge of the internal layout of the Java object.

Instead, it must access fields and methods through indexes returned by

the JVM. This allows different JVMs to implement different internal

object layouts with no impact on your native methods.

If you run the Java program, you'll see that the object that's passed from

the Java side is manipulated by your native method. But what exactly is

passed? A pointer or a Java reference? And what is the garbage collector

doing during native method calls?

The garbage collector continues to operate during native method

execution, but it's guaranteed that your objects will not be garbage-

collected during a native method call. To ensure this, local references are

created before, and destroyed right after, the native method call. Since

their lifetime wraps the call, you know that the objects will be valid

throughout the native method call.

Since these references are created and subsequently destroyed every time

the function is called, you cannot make local copies in your native

Appendix B: The Java Native Interface (JNI)

1073

methods, in static variables. If you want a reference that lasts across

function invocations, you need a global reference. Global references are

not created by the JVM, but the programmer can make a global reference

out of a local one by calling specific JNI functions. When you create a

global reference, you become responsible for the lifetime of the referenced

object. The global reference (and the object it refers to) will be in memory

until the programmer explicitly frees the reference with the appropriate

JNI function. It's similar to malloc( ) and free( ) in C.

JNI and Java exceptions

With JNI, Java exceptions can be thrown, caught, printed, and rethrown

just as they are inside a Java program. But it's up to the programmer to

call dedicated JNI functions to deal with exceptions. Here are the JNI

functions for exception handling:

♦ Throw( )

Throws an existing exception object. Used in native methods to rethrow

an exception.

♦ ThrowNew( )

Generates a new exception object and throws it.

♦ ExceptionOccurred( )

Determines if an exception was thrown and not yet cleared.

♦ ExceptionDescribe( )

Prints an exception and the stack trace.

♦ ExceptionClear( )

Clears a pending exception.

♦ FatalError( )

Raises a fatal error. Does not return.

Among these, you can't ignore ExceptionOccurred( ) and

ExceptionClear( ). Most JNI functions can generate exceptions, and

there is no language feature that you can use in place of a Java try block,

so you must call ExceptionOccurred( ) after each JNI function call to

see if an exception was thrown. If you detect an exception, you may

1074

Thinking in Java

choose to handle it (and possibly rethrow it). You must make certain,

however, that the exception is eventually cleared. This can be done in your

function using ExceptionClear( ) or in some other function if the

exception is rethrown, but it must be done.

You must ensure that the exception is cleared, because otherwise the

results will be unpredictable if you call a JNI function while an exception

is pending. There are few JNI functions that are safe to call during an

exception; among these, of course, are all the exception handling

functions.

JNI and threading

Since Java is a multithreaded language, several threads can call a native

method concurrently. (The native method might be suspended in the

middle of its operation when a second thread calls it.) It's entirely up to

the programmer to guarantee that the native call is thread-safe; i.e., it

does not modify shared data in an unmonitored way. Basically, you have

two options: declare the native method as synchronized, or implement

some other strategy within the native method to ensure correct,

concurrent data manipulation.

Also, you should never pass the JNIEnv pointer across threads, since the

internal structure it points to is allocated on a per-thread basis and

contains information that makes sense only in that particular thread.

Using a preexisting code

base

The easiest way to implement JNI native methods is to start writing

native method prototypes in a Java class, compile that class, and run the

.class file through javah. But what if you have a large, preexisting code

base that you want to call from Java? Renaming all the functions in your

DLLs to match the JNI name mangling convention is not a viable

solution. The best approach is to write a wrapper DLL "outside" your

original code base. The Java code calls functions in this new DLL, which

in turn calls your original DLL functions. This solution is not just a work-

Appendix B: The Java Native Interface (JNI)

1075

around; in most cases you must do this anyway because you must call JNI

functions on the object references before you can use them.

Additional information

You can find further introductory material, including a C (rather than

C++) example and discussion of Microsoft issues, in Appendix A of the

first edition of this book, which can be found on the CD ROM bound in

with this book, or in a free download from . More

extensive information is available at java.sun.com (in the search engine,

select "training & tutorials" for keywords "native methods"). Chapter 11 of

Core Java 2, Volume II, by Horstmann & Cornell (Prentice-Hall, 2000)

gives excellent coverage of native methods.

1076

Thinking in Java

C: Java

Programming

Guidelines

This appendix contains suggestions to help guide you in

performing low-level program design, and in writing code.

Naturally, these are guidelines and not rules. The idea is to use them as

inspirations, and to remember that there are occasional situations where

you need to bend or break a rule.

Design

Elegance always pays off. In the short term it might seem like it

takes much longer to come up with a truly graceful solution to a

problem, but when it works the first time and easily adapts to new

situations instead of requiring hours, days, or months of struggle,

you'll see the rewards (even if no one can measure them). Not only

does it give you a program that's easier to build and debug, but it's

also easier to understand and maintain, and that's where the

financial value lies. This point can take some experience to

understand, because it can appear that you're not being productive

while you're making a piece of code elegant. Resist the urge to

hurry; it will only slow you down.

First make it work, then make it fast. This is true even if you

are certain that a piece of code is really important and that it will be

a principal bottleneck in your system. Don't do it. Get the system

going first with as simple a design as possible. Then if it isn't going

fast enough, profile it. You'll almost always discover that "your"

1077

bottleneck isn't the problem. Save your time for the really

important stuff.

Remember the "divide and conquer" principle. If the

problem you're looking at is too confusing, try to imagine what the

basic operation of the program would be, given the existence of a

magic "piece" that handles the hard parts. That "piece" is an

object--write the code that uses the object, then look at the object

and encapsulate its hard parts into other objects, etc.

Separate the class creator from the class user (client

programmer). The class user is the "customer" and doesn't need

or want to know what's going on behind the scenes of the class. The

class creator must be the expert in class design and write the class

so that it can be used by the most novice programmer possible, yet

still work robustly in the application. Library use will be easy only if

it's transparent.

When you create a class, attempt to make your names so

clear that comments are unnecessary. Your goal should be to

make the client programmer's interface conceptually simple. To

this end, use method overloading when appropriate to create an

intuitive, easy-to-use interface.

Your analysis and design must produce, at minimum, the

classes in your system, their public interfaces, and their

relationships to other classes, especially base classes. If

your design methodology produces more than that, ask yourself if

all the pieces produced by that methodology have value over the

lifetime of the program. If they do not, maintaining them will cost

you. Members of development teams tend not to maintain anything

that does not contribute to their productivity; this is a fact of life

that many design methods don't account for.

Automate everything. Write the test code first (before you write

the class), and keep it with the class. Automate the running of your

tests through a makefile or similar tool. This way, any changes can

be automatically verified by running the test code, and you'll

immediately discover errors. Because you know that you have the

safety net of your test framework, you will be bolder about making

1078

Thinking in Java

sweeping changes when you discover the need. Remember that the

greatest improvements in languages come from the built-in testing

provided by type checking, exception handling, etc., but those

features take you only so far. You must go the rest of the way in

creating a robust system by filling in the tests that verify features

that are specific to your class or program.

Write the test code first (before you write the class) in

order to verify that your class design is complete. If you

can't write test code, you don't know what your class looks like. In

addition, the act of writing the test code will often flush out

additional features or constraints that you need in the class--these

features or constraints don't always appear during analysis and

design. Tests also provide example code showing how your class

can be used.

All software design problems can be simplified by

introducing an extra level of conceptual indirection. This

fundamental rule of software engineering1 is the basis of

abstraction, the primary feature of object-oriented programming.

10.

An indirection should have a meaning (in concert with

guideline 9). This meaning can be something as simple as "putting

commonly used code in a single method." If you add levels of

indirection (abstraction, encapsulation, etc.) that don't have

meaning, it can be as bad as not having adequate indirection.

11.

Make classes as atomic as possible. Give each class a single,

clear purpose. If your classes or your system design grows too

complicated, break complex classes into simpler ones. The most

obvious indicator of this is sheer size: if a class is big, chances are

it's doing too much and should be broken up.

Clues to suggest redesign of a class are:

1) A complicated switch statement: consider using polymorphism.

2) A large number of methods that cover broadly different types of

operations: consider using several classes.

1 Explained to me by Andrew Koenig.

Appendix C: Java Programming Guidelines

1079

3) A large number of member variables that concern broadly

different characteristics: consider using several classes.

12.

Watch for long argument lists. Method calls then become

difficult to write, read, and maintain. Instead, try to move the

method to a class where it is (more) appropriate, and/or pass

objects in as arguments.

13.

Don't repeat yourself. If a piece of code is recurring in many

methods in derived classes, put that code into a single method in

the base class and call it from the derived-class methods. Not only

do you save code space, you provide for easy propagation of

changes. Sometimes the discovery of this common code will add

valuable functionality to your interface.

14.

Watch for switch statements or chained if-else clauses.

This is typically an indicator of type-check coding, which means

you are choosing what code to execute based on some kind of type

information (the exact type may not be obvious at first). You can

usually replace this kind of code with inheritance and

polymorphism; a polymorphic method call will perform the type

checking for you, and allow for more reliable and easier

extensibility.

15.

From a design standpoint, look for and separate things

that change from things that stay the same. That is, search

for the elements in a system that you might want to change without

forcing a redesign, then encapsulate those elements in classes. You

can learn significantly more about this concept in Thinking in

Patterns with Java, downloadable at .

16.

Don't extend fundamental functionality by subclassing. If

an interface element is essential to a class it should be in the base

class, not added during derivation. If you're adding methods by

inheriting, perhaps you should rethink the design.

17.

Less is more. Start with a minimal interface to a class, as small

and simple as you need to solve the problem at hand, but don't try

to anticipate all the ways that your class might be used. As the class

is used, you'll discover ways you must expand the interface.

1080

Thinking in Java

However, once a class is in use you cannot shrink the interface

without disturbing client code. If you need to add more methods,

that's fine; it won't disturb code, other than forcing recompiles. But

even if new methods replace the functionality of old ones, leave the

existing interface alone (you can combine the functionality in the

underlying implementation if you want). If you need to expand the

interface of an existing method by adding more arguments, create

an overloaded method with the new arguments; this way you won't

disturb any existing calls to the existing method.

18.

Read your classes aloud to make sure they're logical. Refer

to the relationship between a base class and derived class as "is-a"

and member objects as "has-a."

19.

When deciding between inheritance and composition, ask

if you need to upcast to the base type. If not, prefer

composition (member objects) to inheritance. This can eliminate

the perceived need for multiple base types. If you inherit, users will

think they are supposed to upcast.

20.

Use data members for variation in value and method

overriding for variation in behavior. That is, if you find a

class that uses state variables along with methods that switch

behavior based on those variables, you should probably redesign it

to express the differences in behavior within subclasses and

overridden methods.

21.

Watch for overloading. A method should not conditionally

execute code based on the value of an argument. In this case, you

should create two or more overloaded methods instead.

22.

Use exception hierarchies--preferably derived from specific

appropriate classes in the standard Java exception hierarchy. The

person catching the exceptions can then catch the specific types of

exceptions, followed by the base type. If you add new derived

exceptions, existing client code will still catch the exception

through the base type.

23.

Sometimes simple aggregation does the job. A "passenger

comfort system" on an airline consists of disconnected elements:

Appendix C: Java Programming Guidelines

1081

seat, air conditioning, video, etc., and yet you need to create many

of these in a plane. Do you make private members and build a

whole new interface? No--in this case, the components are also

part of the public interface, so you should create public member

objects. Those objects have their own private implementations,

which are still safe. Be aware that simple aggregation is not a

solution to be used often, but it does happen.

24.

Consider the perspective of the client programmer and

the person maintaining the code. Design your class to be as

obvious as possible to use. Anticipate the kind of changes that will

be made, and design your class so that those changes will be easy.

25.

Watch out for "giant object syndrome." This is often an

affliction of procedural programmers who are new to OOP and who

end up writing a procedural program and sticking it inside one or

two giant objects. With the exception of application frameworks,

objects represent concepts in your application, not the application.

26.

If you must do something ugly, at least localize the

ugliness inside a class.

27.

If you must do something nonportable, make an

abstraction for that service and localize it within a class.

This extra level of indirection prevents the nonportability from

being distributed throughout your program. (This idiom is

embodied in the Bridge Pattern).

28.

Objects should not simply hold some data. They should also

have well-defined behaviors. (Occasionally, "data objects" are

appropriate, but only when used expressly to package and

transport a group of items when a generalized container is

innappropriate.)

29.

Choose composition first when creating new classes from

existing classes. You should only used inheritance if it is

required by your design. If you use inheritance where composition

will work, your designs will become needlessly complicated.

30.

Use inheritance and method overriding to express

differences in behavior, and fields to express variations in

1082

Thinking in Java

state. An extreme example of what not to do is inheriting different

classes to represent colors instead of using a "color" field.

31.

Watch out for variance. Two semantically different objects may

have identical actions, or responsibilities, and there is a natural

temptation to try to make one a subclass of the other just to benefit

from inheritance. This is called variance, but there's no real

justification to force a superclass/subclass relationship where it

doesn't exist. A better solution is to create a general base class that

produces an interface for both as derived classes--it requires a bit

more space, but you still benefit from inheritance, and will

probably make an important discovery about the design.

32.

Watch out for limitation during inheritance. The clearest

designs add new capabilities to inherited ones. A suspicious design

removes old capabilities during inheritance without adding new

ones. But rules are made to be broken, and if you are working from

an old class library, it may be more efficient to restrict an existing

class in its subclass than it would be to restructure the hierarchy so

your new class fits in where it should, above the old class.

33.

Use design patterns to eliminate "naked functionality."

That is, if only one object of your class should be created, don't bolt

ahead to the application and write a comment "Make only one of

these." Wrap it in a singleton. If you have a lot of messy code in

your main program that creates your objects, look for a creational

pattern like a factory method in which you can encapsulate that

creation. Eliminating "naked functionality" will not only make your

code much easier to understand and maintain, it will also make it

more bulletproof against the well-intentioned maintainers that

come after you.

34.

Watch out for "analysis paralysis." Remember that you must

usually move forward in a project before you know everything, and

that often the best and fastest way to learn about some of your

unknown factors is to go to the next step rather than trying to

figure it out in your head. You can't know the solution until you

have the solution. Java has built-in firewalls; let them work for

Appendix C: Java Programming Guidelines

1083

you. Your mistakes in a class or set of classes won't destroy the

integrity of the whole system.

35.

When you think you've got a good analysis, design, or

implementation, do a walkthrough. Bring someone in from

outside your group--this doesn't have to be a consultant, but can be

someone from another group within your company. Reviewing

your work with a fresh pair of eyes can reveal problems at a stage

when it's much easier to fix them, and more than pays for the time

and money "lost" to the walkthrough process.

Implementation

36.

In general, follow the Sun coding conventions. These are

available at

java.sun.com/docs/codeconv/index.html (the code in this book

follows these conventions as much as I was able). These are used

for what constitutes arguably the largest body of code that the

largest number of Java programmers will be exposed to. If you

doggedly stick to the coding style you've always used, you will make

it harder for your reader. Whatever coding conventions you decide

on, ensure they are consistent throughout the project. There is a

free tool to automatically reformat Java code at:

home.wtal.de/software-solutions/jindent.

37.

Whatever coding style you use, it really does make a

difference if your team (and even better, your company)

standardizes on it. This means to the point that everyone

considers it fair game to fix someone else's coding style if it doesn't

conform. The value of standardization is that it takes less brain

cycles to parse the code, so that you can focus more on what the

code means.

38.

Follow standard capitalization rules. Capitalize the first letter

of class names. The first letter of fields, methods, and objects

(references) should be lowercase. All identifiers should run their

words together, and capitalize the first letter of all intermediate

words. For example:

ThisIsAClassName

1084

Thinking in Java

thisIsAMethodOrFieldName

Capitalize all the letters of static final primitive identifiers that

have constant initializers in their definitions. This indicates they

are compile-time constants.

Packages are a special case--they are all lowercase letters, even

for intermediate words. The domain extension (com, org, net, edu,

etc.) should also be lowercase. (This was a change between Java 1.1

and Java 2.)

39.

Don't create your own "decorated" private data member

names. This is usually seen in the form of prepended underscores

and characters. Hungarian notation is the worst example of this,

where you attach extra characters that indicate data type, use,

location, etc., as if you were writing assembly language and the

compiler provided no extra assistance at all. These notations are

confusing, difficult to read, and unpleasant to enforce and

maintain. Let classes and packages do the name scoping for you.

40.

Follow a "canonical form" when creating a class for general-

purpose use. Include definitions for equals( ), hashCode( ),

toString( ), clone( ) (implement Cloneable), and implement

Comparable and Serializable.

41.

Use the JavaBeans "get," "set," and "is" naming

conventions for methods that read and change private fields,

even if you don't think you're making a JavaBean at the time. Not

only does it make it easy to use your class as a Bean, but it's a

standard way to name these kinds of methods and so will be more

easily understood by the reader.

42.

For each class you create, consider including a static

public test( ) that contains code to test that class. You don't

need to remove the test code to use the class in a project, and if you

make any changes you can easily rerun the tests. This code also

provides examples of how to use your class.

43.

Sometimes you need to inherit in order to access

protected members of the base class. This can lead to a

perceived need for multiple base types. If you don't need to upcast,

first derive a new class to perform the protected access. Then make

Appendix C: Java Programming Guidelines

1085

that new class a member object inside any class that needs to use it,

rather than inheriting.

44.

Avoid the use of final methods for efficiency purposes.

Use final only when the program is running, but not fast enough,

and your profiler has shown you that a method invocation is the

bottleneck.

45.

If two classes are associated with each other in some

functional way (such as containers and iterators), try to

make one an inner class of the other. This not only

emphasizes the association between the classes, but it allows the

class name to be reused within a single package by nesting it within

another class. The Java containers library does this by defining an

inner Iterator class inside each container class, thereby providing

the containers with a common interface. The other reason you'll

want to use an inner class is as part of the private

implementation. Here, the inner class beneficial for

implementation hiding rather than the class association and

prevention of namespace pollution noted above.

46.

Anytime you notice classes that appear to have high

coupling with each other, consider the coding and

maintenance improvements you might get by using inner

classes. The use of inner classes will not uncouple the classes, but

rather make the coupling explicit and more convenient.

47.

Don't fall prey to premature optimization. This way lies

madness. In particular, don't worry about writing (or avoiding)

native methods, making some methods final, or tweaking code to

be efficient when you are first constructing the system. Your

primary goal should be to prove the design, unless the design

requires a certain efficiency.

48.

Keep scopes as small as possible so the visibility and

lifetime of your objects are as small as possible. This

reduces the chance of using an object in the wrong context and

hiding a difficult-to-find bug. For example, suppose you have a

container and a piece of code that iterates through it. If you copy

that code to use with a new container, you may accidentally end up

1086

Thinking in Java

using the size of the old container as the upper bound of the new

one. If, however, the old container is out of scope, the error will be

caught at compile-time.

49.

Use the containers in the standard Java library. Become

proficient with their use and you'll greatly increase your

productivity. Prefer ArrayList for sequences, HashSet for sets,

HashMap for associative arrays, and LinkedList for stacks

(rather than Stack) and queues.

50.

For a program to be robust, each component must be

robust. Use all the tools provided by Java: access control,

exceptions, type checking, and so on, in each class you create. That

way you can safely move to the next level of abstraction when

building your system.

51.

Prefer compile-time errors to run-time errors. Try to

handle an error as close to the point of its occurrence as possible.

Prefer dealing with the error at that point to throwing an exception.

Catch any exceptions in the nearest handler that has enough

information to deal with them. Do what you can with the exception

at the current level; if that doesn't solve the problem, rethrow the

exception.

52.

Watch for long method definitions. Methods should be brief,

functional units that describe and implement a discrete part of a

class interface. A method that is long and complicated is difficult

and expensive to maintain, and is probably trying to do too much

all by itself. If you see such a method, it indicates that, at the least,

it should be broken up into multiple methods. It may also suggest

the creation of a new class. Small methods will also foster reuse

within your class. (Sometimes methods must be large, but they

should still do just one thing.)

53.

Keep things as "private as possible." Once you publicize an

aspect of your library (a method, a class, a field), you can never

take it out. If you do, you'll wreck somebody's existing code, forcing

them to rewrite and redesign. If you publicize only what you must,

you can change everything else with impunity, and since designs

tend to evolve this is an important freedom. In this way,

Appendix C: Java Programming Guidelines

1087

implementation changes will have minimal impact on derived

classes. Privacy is especially important when dealing with

multithreading--only private fields can be protected against un-

synchronized use.

54.

Use comments liberally, and use the javadoc comment-

documentation syntax to produce your program

documentation. However, the comments should add geniune

meaning to the code; comments that only reiterate what the code is

clearly expressing are annoying. Note that the typical verbose detail

of Java class and method names reduce the need for as many

comments.

55.

Avoid using "magic numbers"--which are numbers hard-

wired into code. These are a nightmare if you need to change them,

since you never know if "100" means "the array size" or "something

else entirely." Instead, create a constant with a descriptive name

and use the constant identifier throughout your program. This

makes the program easier to understand and much easier to

maintain.

56.

When creating constructors, consider exceptions. In the

best case, the constructor won't do anything that throws an

exception. In the next-best scenario, the class will be composed and

inherited from robust classes only, so they will need no cleanup if

an exception is thrown. Otherwise, you must clean up composed

classes inside a finally clause. If a constructor must fail, the

appropriate action is to throw an exception, so the caller doesn't

continue blindly, thinking that the object was created correctly.

57.

If your class requires any cleanup when the client

programmer is finished with the object, place the cleanup

code in a single, well-defined method--with a name like

cleanup( ) that clearly suggests its purpose. In addition, place a

boolean flag in the class to indicate whether the object has been

cleaned up so that finalize( ) can check for "the death condition"

(see Chapter 4).

58.

The responsibility of finalize( ) can only be to verify "the

death condition" of an object for debugging. (See Chapter

1088

Thinking in Java

4.) In special cases, it might be needed to release memory that

would not otherwise be released by the garbage collector. Since the

garbage collector might not get called for your object, you cannot

use finalize( ) to perform necessary cleanup. For that you must

create your own "cleanup" method. In the finalize( ) method for

the class, check to make sure that the object has been cleaned up

and throw a class derived from RuntimeException if it hasn't, to

indicate a programming error. Before relying on such a scheme,

ensure that finalize( ) works on your system. (You might need to

call System.gc( ) to ensure this behavior.)

59.

If an object must be cleaned up (other than by garbage

collection) within a particular scope, use the following

approach: Initialize the object and, if successful, immediately

enter a try block with a finally clause that performs the cleanup.

60.

When overriding finalize( ) during inheritance,

remember to call super.finalize( ). (This is not necessary if

Object is your immediate superclass.) You should call

super.finalize( ) as the final act of your overridden finalize( )

rather than the first, to ensure that base-class components are still

valid if you need them.

61.

When you are creating a fixed-size container of objects,

transfer them to an array--especially if you're returning this

container from a method. This way you get the benefit of the

array's compile-time type checking, and the recipient of the array

might not need to cast the objects in the array in order to use them.

Note that the base-class of the containers library,

java.util.Collection, has two toArray( ) methods to accomplish

this.

62.

Choose interfaces over abstract classes. If you know

something is going to be a base class, your first choice should be to

make it an interface, and only if you're forced to have method

definitions or member variables should you change it to an

abstract class. An interface talks about what the client wants to

do, while a class tends to focus on (or allow) implementation

details.

Appendix C: Java Programming Guidelines

1089

63.

Inside constructors, do only what is necessary to set the

object into the proper state. Actively avoid calling other

methods (except for final methods) since those methods can be

overridden by someone else to produce unexpected results during

construction. (See Chapter 7 for details.) Smaller, simpler

constructors are less likely to throw exceptions or cause problems.

64.

To avoid a highly frustrating experience, make sure that

there is only one unpackaged class of each name

anywhere in your classpath. Otherwise, the compiler can find

the identically-named other class first, and report error messages

that make no sense. If you suspect that you are having a classpath

problem, try looking for .class files with the same names at each of

the starting points in your classpath. Ideally, put all your classes

within packages.

65.

Watch out for accidental overloading. If you attempt to

override a base-class method and you don't quite get the spelling

right, you'll end up adding a new method rather than overriding an

existing method. However, this is perfectly legal, so you won't get

any error message from the compiler or run-time system--your

code simply won't work correctly.

66.

Watch out for premature optimization. First make it work,

then make it fast--but only if you must, and only if it's proven that

there is a performance bottleneck in a particular section of your

code. Unless you have used a profiler to discover a bottleneck, you

will probably be wasting your time. The hidden cost of performance

tweaks is that your code becomes less understandable and

maintainable.

67.

Remember that code is read much more than it is written.

Clean designs make for easy-to-understand programs, but

comments, detailed explanations, and examples are invaluable.

They will help both you and everyone who comes after you. If

nothing else, the frustration of trying to ferret out useful

information from the online Java documentation should convince

you.

1090

Thinking in Java

D: Resources

Software

The JDK from java.sun.com. Even if you choose to use a third-party

development environment, it's always a good idea to have the JDK on

hand in case you come up against what might be a compiler error. The

JDK is the touchstone, and if there is a bug in it, chances are it will be

well-known.

The HTML Java documentation from java.sun.com. I have never

found a reference book on the standard Java libraries that wasn't out of

date or missing information. Although the HTML documentation from

Sun is shot-through with small bugs and is sometimes unusably terse, all

the classes and methods are at least there. People are sometimes

uncomfortable at first using an online resource rather than a printed

book, but it's worth your while to get over this and open the HTML docs

first, so you can at least get the big picture. If you can't figure it out at that

point, then reach for the printed books.

Books

Thinking in Java, 1st Edition. Available as fully-indexed, color-

syntax-highlighted HTML on the CD ROM bound in with this book, or as

a free download from . Includes older material and

material that was not considered interesting enough to carry through to

the 2nd edition.

Core Java 2, by Horstmann & Cornell, Volume I--Fundamentals

(Prentice-Hall, 1999). Volume II--Advanced Features, 2000. Huge,

comprehensive, and the first place I go when I'm hunting for answers. The

book I recommend when you've completed Thinking in Java and need to

cast a bigger net.

1091

Java in a Nutshell: A Desktop Quick Reference, 2nd Edition, by

David Flanagan (O'Reilly, 1997). A compact summary of the online Java

documentation. Personally, I prefer to browse the docs from java.sun.com

online, especially since they change so often. However, many folks still

like printed documentation and this fits the bill; it also provides more

discussion than the online documents.

The Java Class Libraries: An Annotated Reference, by Patrick

Chan and Rosanna Lee (Addison-Wesley, 1997). What the online

reference should have been: enough description to make it usable. One of

the technical reviewers for Thinking in Java said, "If I had only one Java

book, this would be it (well, in addition to yours, of course)." I'm not as

thrilled with it as he is. It's big, it's expensive, and the quality of the

examples doesn't satisfy me. But it's a place to look when you're stuck and

it seems to have more depth (and sheer size) than Java in a Nutshell.

Java Network Programming, by Elliotte Rusty Harold (O'Reilly,

1997). I didn't begin to understand Java networking until I found this

book. I also find his Web site, Café au Lait, to be a stimulating,

opinionated, and up-to-date perspective on Java developments,

unencumbered by allegiances to any vendors. His regular updates keep up

with fast-changing news about Java. See metalab.unc.edu/javafaq/.

JDBC Database Access with Java, by Hamilton, Cattell & Fisher

(Addison-Wesley, 1997). If you know nothing about SQL and databases,

this is a nice, gentle introduction. It also contains some of the details as

well as an "annotated reference" to the API (again, what the online

reference should have been). The drawback, as with all books in The Java

Series ("The ONLY Books Authorized by JavaSoft") is that it's been

whitewashed so that it says only wonderful things about Java--you won't

find out about any dark corners in this series.

Java Programming with CORBA, by Andreas Vogel & Keith Duddy

(John Wiley & Sons, 1997). A serious treatment of the subject with code

examples for three Java ORBs (Visibroker, Orbix, Joe).

Design Patterns, by Gamma, Helm, Johnson & Vlissides (Addison-

Wesley, 1995). The seminal book that started the patterns movement in

programming.

1092

Thinking in Java

Practical Algorithms for Programmers, by Binstock & Rex

(Addison-Wesley, 1995). The algorithms are in C, so they're fairly easy to

translate into Java. Each algorithm is thoroughly explained.

Analysis & design

Extreme Programming Explained, by Kent Beck (Addison-Wesley,

2000). I love this book. Yes, I tend to take a radical approach to things but

I've always felt that there could be a much different, much better program

development process, and I think XP comes pretty darn close. The only

book that has had a similar impact on me was PeopleWare (described

below), which talks primarily about the environment and dealing with

corporate culture. Extreme Programming Explained talks about

programming, and turns most things, even recent "findings," on their ear.

They even go so far as to say that pictures are OK as long as you don't

spend too much time on them and are willing to throw them away. (You'll

notice that this book does not have the "UML stamp of approval" on its

cover.) I could see deciding whether to work for a company based solely

on whether they used XP. Small book, small chapters, effortless to read,

exciting to think about. You start imagining yourself working in such an

atmosphere and it brings visions of a whole new world.

UML Distilled, 2nd Edition, by Martin Fowler (Addison-Wesley,

2000). When you first encounter UML, it is daunting because there are so

many diagrams and details. According to Fowler, most of this stuff is

unnecessary so he cuts through to the essentials. For most projects, you

only need to know a few diagramming tools, and Fowler's goal is to come

up with a good design rather than worry about all the artifacts of getting

there. A nice, thin, readable book; the first one you should get if you need

to understand UML.

UML Toolkit, by Hans-Erik Eriksson & Magnus Penker, (John Wiley &

Sons, 1997). Explains UML and how to use it, and has a case study in

Java. An accompanying CD ROM contains the Java code and a cut-down

version of Rational Rose. An excellent introduction to UML and how to

use it to build a real system.

The Unified Software Development Process, by Ivar Jacobsen,

Grady Booch, and James Rumbaugh (Addison-Wesley, 1999). I went in

fully prepared to dislike this book. It seemed to have all the makings of a

Appendix D: Resources

1093

boring college text. I was pleasantly surprised--only pockets of the book

contain explanations that seem as if those concepts aren't clear to the

authors. The bulk of the book is not only clear, but enjoyable. And best of

all, the process makes a lot of practical sense. It's not Extreme

Programming (and does not have their clarity about testing) but it's also

part of the UML juggernaut--even if you can't get XP adopted, most

people have climbed aboard the "UML is good" bandwagon (regardless of

their actual level of experience with it) and so you can probably get it

adopted. I think this book should be the flagship of UML, and the one you

can read after Fowler's UML Distilled when you want more detail.

Before you choose any method, it's helpful to gain perspective from those

who are not trying to sell one. It's easy to adopt a method without really

understanding what you want out of it or what it will do for you. Others

are using it, which seems a compelling reason. However, humans have a

strange little psychological quirk: If they want to believe something will

solve their problems, they'll try it. (This is experimentation, which is

good.) But if it doesn't solve their problems, they may redouble their

efforts and begin to announce loudly what a great thing they've

discovered. (This is denial, which is not good.) The assumption here may

be that if you can get other people in the same boat, you won't be lonely,

even if it's going nowhere (or sinking).

This is not to suggest that all methodologies go nowhere, but that you

should be armed to the teeth with mental tools that help you stay in

experimentation mode ("It's not working; let's try something else") and

out of denial mode ("No, that's not really a problem. Everything's

wonderful, we don't need to change"). I think the following books, read

before you choose a method, will provide you with these tools.

Software Creativity, by Robert Glass (Prentice-Hall, 1995). This is the

best book I've seen that discusses perspective on the whole methodology

issue. It's a collection of short essays and papers that Glass has written

and sometimes acquired (P.J. Plauger is one contributor), reflecting his

many years of thinking and study on the subject. They're entertaining and

only long enough to say what's necessary; he doesn't ramble and bore you.

He's not just blowing smoke, either; there are hundreds of references to

other papers and studies. All programmers and managers should read this

book before wading into the methodology mire.

1094

Thinking in Java

Software Runaways: Monumental Software Disasters, by

Robert Glass (Prentice-Hall, 1997). The great thing about this book is that

it brings to the forefront what we don't talk about: how many projects not

only fail, but fail spectacularly. I find that most of us still think "That can't

happen to me" (or "That can't happen again"), and I think this puts us at

a disadvantage. By keeping in mind that things can always go wrong,

you're in a much better position to make them go right.

Peopleware, 2nd Edition, by Tom Demarco and Timothy Lister (Dorset

House, 1999). Although they have backgrounds in software development,

this book is about projects and teams in general. But the focus is on the

people and their needs, rather than the technology and its needs. They

talk about creating an environment where people will be happy and

productive, rather than deciding what rules those people should follow to

be adequate components of a machine. This latter attitude, I think, is the

biggest contributor to programmers smiling and nodding when XYZ

method is adopted and then quietly doing whatever they've always done.

Complexity, by M. Mitchell Waldrop (Simon & Schuster, 1992). This

chronicles the coming together of a group of scientists from different

disciplines in Santa Fe, New Mexico, to discuss real problems that their

individual disciplines couldn't solve (the stock market in economics, the

initial formation of life in biology, why people do what they do in

sociology, etc.). By crossing physics, economics, chemistry, math,

computer science, sociology, and others, a multidisciplinary approach to

these problems is developing. But more important, a different way of

thinking about these ultra-complex problems is emerging: Away from

mathematical determinism and the illusion that you can write an equation

that predicts all behavior, and toward first observing and looking for a

pattern and trying to emulate that pattern by any means possible. (The

book chronicles, for example, the emergence of genetic algorithms.) This

kind of thinking, I believe, is useful as we observe ways to manage more

and more complex software projects.

Python

Learning Python, by Mark Lutz and David Ascher (O'Reilly, 1999). A

nice programmer's introduction to what is rapidly becoming my favorite

language, an excellent companion to Java. The book includes an

Appendix D: Resources

1095

introduction to JPython, which allows you to combine Java and Python in

a single program (the JPython interpreter is compiled to pure Java

bytecodes, so there is nothing special you need to add to accomplish this).

This language union promises great possibilities.

My own list of books

Listed in order of publication. Not all of these are currently available.

Computer Interfacing with Pascal & C, (Self-published via the

Eisys imprint, 1988. Only available via ). An

introduction to electronics from back when CP/M was still king and DOS

was an upstart. I used high-level languages and often the parallel port of

the computer to drive various electronic projects. Adapted from my

columns in the first and best magazine I wrote for, Micro Cornucopia. (To

paraphrase Larry O'Brien, long-time editor of Software Development

Magazine: the best computer magazine ever published--they even had

plans for building a robot in a flower pot!) Alas, Micro C became lost long

before the Internet appeared. Creating this book was an extremely

satisfying publishing experience.

Using C++, (Osborne/McGraw-Hill, 1989). One of the first books out on

C++. This is out of print and replaced by its second edition, the renamed

C++ Inside & Out.

C++ Inside & Out, (Osborne/McGraw-Hill, 1993). As noted, actually

the 2nd edition of Using C++. The C++ in this book is reasonably

accurate, but it's circa 1992 and Thinking in C++ is intended to replace it.

You can find out more about this book and download the source code at

Thinking in C++, 1st Edition, (Prentice-Hall, 1995).

Thinking in C++, 2nd Edition, Volume 1, (Prentice-Hall, 2000).

Downloadable from .

Black Belt C++, the Master's Collection, Bruce Eckel, editor (M&T

Books, 1994). Out of print. A collection of chapters by various C++

luminaries based on their presentations in the C++ track at the Software

Development Conference, which I chaired. The cover on this book

stimulated me to gain control over all future cover designs.

1096

Thinking in Java

Thinking in Java, 1st Edition, (Prentice-Hall, 1998). The first edition

of this book won the Software Development Magazine Productivity

Award, the Java Developer's Journal Editor's Choice Award, and the

JavaWorld Reader's Choice Award for best book. Downloadable from

Appendix D: Resources

1097

Index

Please note that some names will be duplicated in

capitalized form. Following Java style, the capitalized

names refer to Java classes, while lowercase names refer

to a general concept.

access: class · 263; control · 243, 267;

- · 139

inner classes & access rights · 376;

! · 143

package access and friendly · 255;

!= · 141; operator · 1025

specifiers · 36, 243, 255; within a

& · 146

directory, via the default package · 257

&& · 143

action command · 765

&= · 147

ActionEvent · 766, 814

@deprecated · 128

ActionListener · 712

[ ]: indexing operator [ ] · 231

actor, in use cases · 77

^ · 146

adapters: listener adapters · 729

^= · 147

add( ), ArrayList · 450

| · 146

addActionListener( ) · 811, 857

|| · 143

addChangeListener · 771

|= · 147

addition · 137

`+': operator + for String · 1054

addListener · 722

+ · 139

addXXXListener( ) · 723

< · 141

Adler32 · 608

<< · 147

aggregate array initialization · 231

<<= · 147

aggregation · 37

<= · 141

aliasing · 136; and String · 1054; during a

== · 141; operator · 1025; vs. equals( ) · 645

method call · 1014

> · 141

align · 697

>= · 141

alphabetic vs. lexicographic sorting · 436

>> · 147

AlreadyBoundException · 978

>>= · 147

analysis: and design, object-oriented · 71;

paralysis · 72; requirements analysis · 75

AND: bitwise · 154; logical (&&) · 143

anonymous inner class · 370, 576, 709,

875; and constructors · 375

abstract: class · 326; inheriting from an

anonymous inner class, and table-driven

abstract class · 326; vs. interface · 356

code · 502

abstract keyword · 327

applet · 692; advantages for client/server

Abstract Window Toolkit (AWT) · 689

systems · 693; align · 697; and packages

AbstractButton · 734

· 699; archive tag, for HTML and JAR

abstraction · 30

files · 793; classpath · 699; codebase ·

AbstractSequentialList · 502

697; combined applets and applications

AbstractSet · 461

· 700; displaying a Web page from

accept( ) · 909

within an applet · 923; name · 697;

packaging applets in a JAR file to

1099

base class · 260, 275, 315; abstract base

optimize loading · 793; parameter · 697;

class · 326; base-class interface · 320;

placing inside a Web page · 695;

constructor · 332; constructors and

restrictions · 692

exceptions · 281; initialization · 278

Applet: combined with application · 839;

Basic: Microsoft Visual Basic · 800

initialization parameters · 839

basic concepts of object-oriented

appletviewer · 698

programming (OOP) · 29

application: application builder · 800;

BASIC language · 92

application framework · 394; combined

BasicArrowButton · 735

applets and applications · 700;

beanbox Bean testing tool · 817

combined with Applet · 839; windowed

BeanInfo: custom BeanInfo · 818

applications · 700

Beans: and Borland's Delphi · 800; and

application framework, and applets · 694

Microsoft's Visual Basic · 800; and

archive tag, for HTML and JAR files · 793

multithreading · 854; application

argument: constructor · 193; final · 298,

builder · 800; beanbox Bean testing tool

577; passing a reference into a method ·

· 817; bound properties · 818;

1014; variable argument lists (unknown

component · 801; constrained

quantity and type of arguments) · 235

properties · 818; custom BeanInfo · 818;

array · 407; associative array · 477;

custom property editor · 818; custom

associative array, Map · 442; bounds

property sheet · 818; events · 801;

checking · 232; comparing arrays · 431;

EventSetDescriptors · 808;

copying an array · 429; dynamic

FeatureDescriptor · 818; getBeanInfo( )

aggregate initialization syntax · 412;

· 805; getEventSetDescriptors( ) · 808;

element comparisons · 431; first-class

getMethodDescriptors( ) · 808;

objects · 409; initialization · 231; length

getName( ) · 808;

· 232, 409; multidimensional · 236; of

getPropertyDescriptors( ) · 808;

objects · 409; of primitives · 409; return

getPropertyType( ) · 808;

an array · 413

getReadMethod( ) · 808;

ArrayList · 456, 463, 467, 500, 505; add( )

getWriteMethod( ) · 808; indexed

· 450; and deep copying · 1030; get( ) ·

property · 818; Introspector · 805; JAR

450, 456; size( ) · 451; type-conscious

files for packaging · 816; manifest file ·

ArrayList · 454; used with HashMap ·

816; Method · 808; MethodDescriptors ·

652

808; naming convention · 802;

Arrays class, container utility · 415

properties · 801; PropertyChangeEvent ·

Arrays.asList( ) · 519

818; PropertyDescriptors · 808;

Arrays.binarySearch( ) · 437

ProptertyVetoException · 818; reflection

Arrays.fill( ) · 428

· 801, 804; Serializable · 814; visual

assigning objects · 134

programming · 800

assignment · 134

Beck, Kent · 1093

associative array · 439, 477

Bill Joy · 141

associative arrays (Maps) · 442

binary: numbers · 156; operators · 146

auto-decrement operator · 139

binary numbers, printing · 150

auto-increment operator · 139

binarySearch( ) · 437

automatic type conversion · 273

bind( ) · 976

available( ) · 598

binding: dynamic binding · 316; dynamic,

late, or run-time binding · 311; early ·

45; late · 45; late binding · 316; method

call binding · 315; run-time binding ·

316

bag · 440

BitSet · 522

base: types · 39

bitwise: AND · 154; AND operator (&) ·

base 16 · 156

146; EXCLUSIVE OR XOR (^) · 146;

base 8 · 156

1100

double to integral, truncation · 186;

NOT ~ · 146; operators · 146; OR · 154;

operators · 154

OR operator (|) · 146

catch: catching an exception · 534;

bitwise copy · 1024

catching any exception · 543; keyword ·

blank final · 297

535

blocking: and available( ) · 598; and

CD ROM for book · 20

threads · 859; on I/O · 869

CGI: Common-Gateway Interface · 948

Booch, Grady · 1093

change: vector of change · 397

book: errors, reporting · 23; updates of the

CharArrayReader · 590

book · 22

CharArrayWriter · 590

boolean: operators that won't work with

check box · 748

boolean · 141

CheckedInputStream · 606

Boolean · 169; algebra · 146; and casting ·

CheckedOutputStream · 606

155; vs. C and C++ · 144

Checksum · 608

BorderLayout · 713

class · 32, 262; abstract class · 326; access ·

Borland · 820; Delphi · 800

263; anonymous inner · 709;

bound properties · 818

anonymous inner class · 370, 576, 875;

bounds checking, array · 232

anonymous inner class and constructors

Box, for BoxLayout · 718

· 375; base class · 260, 275, 315; browser

BoxLayout · 717

· 263; class hierarchies and exception

break keyword · 175

handling · 567; class literal · 664, 669;

browser: class browser · 263

creators · 35; defining the interface · 88;

BufferedInputStream · 586

derived class · 315; equivalence, and

BufferedOutputStream · 588

instanceof/isInstance( ) · 672; final

BufferedReader · 563, 591, 597

classes · 301; inheritance diagrams ·

BufferedWriter · 591, 599

293; inheriting from an abstract class ·

business objects/logic · 796

326; inheriting from inner classes · 384;

button: creating your own · 730; radio

initialization & class loading · 304;

button · 750

initialization of data members · 220;

button, Swing · 706

initializing members at point of

ButtonGroup · 736, 750

definition · 221; initializing the base

buttons · 734

class · 278; inner class · 365; inner class

ByteArrayInputStream · 582

nesting within any arbitrary scope · 372;

ByteArrayOutputStream · 583

inner classes · 799; inner classes &

access rights · 376; inner classes and

overriding · 385; inner classes and super

· 385; inner classes and Swing · 722;

inner classes and upcasting · 368; inner

C/C++, interfacing with · 1065

classes in methods & scopes · 370; inner

C++ · 141; copy constructor · 1042;

classes, identifiers and .class files · 387;

Standard Container Library aka STL ·

instance of · 31; intializing the derived

440; strategies for transition to · 93;

class · 278; keyword · 38; loading · 305;

templates · 455; vector class, vs. array

member initialization · 273; multiply-

and ArrayList · 408; why it succeeds · 91

nested · 383; order of initialization ·

callback · 432, 575, 708

223; private inner classes · 397; public

callbacks: and inner classes · 391

class, and compilation units · 245; read-

capacity, of a HashMap or HashSet · 491

only classes · 1047; referring to the

capitalization: Java capitalization style

outer class object in an inner class · 381;

source-code checking tool · 645; of

static inner classes · 379; style of

package names · 116

creating classes · 262; subobject · 278

case statement · 183

Class · 737; Class object · 633, 662, 848;

cast · 47, 201, 661; and containers · 450;

forName( ) · 664, 727; getClass( ) · 544;

and primitive types · 170; from float or

1101

compareTo( ), in java.lang.Comparable ·

getConstructors( ) · 681; getInterfaces( )

432

· 676; getMethods( ) · 681; getName( ) ·

comparing arrays · 431

677; getSuperclass( ) · 676; isInstance ·

compilation unit · 245

671; isInterface( ) · 677; newInstance( ) ·

compile-time constant · 294

676; printInfo( ) · 677; RTTI using the

compiling a Java program · 121

Class object · 674

component, and JavaBeans · 801

Class object · 227

composition · 37, 271; and cloning · 1027;

ClassCastException · 345, 666

and design · 340; and dynamic behavior

classpath · 248, 699; and rmic · 979

change · 341; choosing composition vs.

class-responsibility-collaboration (CRC)

inheritance · 288; combining

cards · 79

composition & inheritance · 281; vs.

cleanup: and garbage collector · 283;

inheritance · 294, 642

performing · 209; with finally · 554

compression: compression library · 606

cleanup, guaranteeing with finalize( ) · 214

concept, high · 75

client programmer · 35; vs. library creator ·

ConcurrentModificationException · 515

243

conditional operator · 151

client, network · 907

conference, Software Development

clipboard: system clipboard · 790

Conference · 10

clone( ) · 1021; and composition · 1027;

Console: Swing display framework in

and inheritance · 1034; Object.clone( ) ·

com.bruceeckel.swing · 702

1025; removing/turning off cloneability

console input · 597

· 1036; super.clone( ) · 1025, 1041;

const, in C++ · 1053

supporting cloning in derived classes ·

constant: compile-time constant · 294;

1036

folding · 294; groups of constant values ·

Cloneable interface · 1022

359; implicit constants, and String ·

CloneNotSupportedException · 1024

1053

close( ) · 597

constrained properties · 818

closure, and inner classes · 391

constructor · 191; and anonymous inner

code: calling non-Java code · 1065; coding

classes · 370; and exception handling ·

standards · 22, 1077; organization · 255;

562; and exceptions · 561; and finally ·

re-use · 271

562; and overloading · 194; and

codebase · 697

polymorphism · 330; arguments · 193;

Collection · 440

base-class constructor · 332; base-class

collection class · 407

constructors and exceptions · 281;

Collections · 511

behavior of polymorphic methods inside

Collections.enumeration( ) · 520

constructors · 337; C++ copy

Collections.fill( ) · 443

constructor · 1042; calling base-class

Collections.reverseOrder() · 434

constructors with arguments · 280;

collision: name · 250

calling from other constructors · 205;

collisions, during hashing · 488

default · 202; default constructors · 196;

com.bruceeckel.swing · 703

initialization during inheritance and

combo box · 751

composition · 281; name · 192; no-arg

comma operator · 152, 175

constructors · 196; order of constructor

Command Pattern · 575

calls with inheritance · 330; return value

comments: and embedded documentation

· 193; static construction clause · 228;

· 122

synthesized default constructor access ·

common interface · 325

681

common pitfalls when using operators ·

Constructor: for reflection · 678

153

consulting & mentoring provided by Bruce

Common-Gateway Interface (CGI) · 948

Eckel · 23

Comparable · 432, 475

Comparator · 434, 475

1102

deep copy · 1020, 1027; and ArrayList ·

container: class · 407, 439; of primitives ·

1030; using serialization to perform

412

deep copying · 1032

container classes, utilities for · 444

default constructor · 196, 202;

continue keyword · 175

synthesizing a default constructor · 279

control: access · 36

default constructor, access the same as the

control framework, and inner classes · 394

class · 681

controlling access · 267

default keyword, in a switch statement ·

conversion: automatic · 273; narrowing

183

conversion · 155, 201; widening

default package · 257

conversion · 155

DefaultMutableTreeNode · 784

cookies: and JSP · 971

defaultReadObject( ) · 629

cookies, and servlets · 955

DefaultTreeModel · 784

copy: deep copy · 1020; shallow copy ·

defaultWriteObject( ) · 629

1019

DeflaterOutputStream · 606

copying an array · 429

Delphi, from Borland · 800

CORBA · 980

Demarco, Tom · 1095

costs, startup · 95

dequeue · 440

coupling · 537

derived: derived class · 315; derived class,

CRC, class-responsibility-collaboration

initializing · 278; types · 39

cards · 79

design · 342; adding more methods to a

CRC32 · 608

design · 268; analysis and design,

createStatement( ) · 930

object-oriented · 71; and composition ·

critical section, and synchronized block ·

340; and inheritance · 339; and

852

mistakes · 268; five stages of object

design · 82; library design · 243; of

object hierarchies · 307; patterns · 86,

design patterns · 266; decorator · 585;

daemon threads · 840

singleton · 266

data: final · 294; primitive data types and

destroy( ) · 877

use with operators · 159; static

destructor · 208, 209, 554; Java doesn't

initialization · 225

have one · 283

data type: equivalence to class · 33

development, incremental · 291

database: flat-file database · 932; Java

diagram: inheritance · 47; use case · 77

DataBase Connectivity (JDBC) · 927;

diagram, class inheritance diagrams · 293

relational database · 933; URL · 928

dialog box · 771

DatabaseMetaData · 938

dialog, file · 776

DataFlavor · 792

dialog, tabbed · 755

Datagram · 923; User Datagram Protocol

dictionary · 477

(UDP) · 923

digital signing · 692

DataInput · 593

directory: and packages · 254; creating

DataInputStream · 586, 591, 597, 599

directories and paths · 578; lister · 574

DataOutput · 593

display framework, for Swing · 702

DataOutputStream · 588, 592, 599

dispose( ) · 772

dead, Thread · 859

division · 137

deadlock, multithreading · 865, 872

documentation: comments & embedded

death condition, and finalize( ) · 214

documentation · 122

decorator design pattern · 585

Domain Name System (DNS) · 905

decoupling: via polymorphism · 46

dotted quad · 905

decoupling through polymorphism · 311

double, literal value marker (D) · 156

decrement operator · 139

do-while · 173

1103

543; changing the point of origin of the

downcast · 293, 343, 666; type-safe

exception · 547; class hierarchies · 567;

downcast in run-time type identification

constructors · 562; creating your own ·

· 665

537; design issues · 565; Error class ·

Drawing lines in Swing · 768

549; Exception class · 549; exception

drop-down list · 751

handler · 535; exception handling · 531;

dynamic: behavior change with

exception matching · 566;

composition · 341; binding · 311, 316

FileNotFoundException · 565;

dynamic aggregate initialization syntax for

fillInStackTrace( ) · 545; finally · 552;

arrays · 412

guarded region · 535; handler · 532;

handling · 283; losing an exception,

pitfall · 557; NullPointerException · 550;

printStackTrace( ) · 545; restrictions ·

558; re-throwing an exception · 545;

early binding · 45, 315

RuntimeException · 550; specification ·

East, BorderLayout · 713

542; termination vs. resumption · 536;

editor, creating one using the Swing

Throwable · 543; throwing an exception

JTextPane · 747

· 533; try · 554; try block · 535; typical

efficiency: and arrays · 408; and final ·

uses of exceptions · 568

302; and threads · 828; when using the

exceptional condition · 532

synchronized keyword · 853

exceptions: and JNI · 1074

EJB · 990

executeQuery( ) · 930

elegance, in programming · 87

Exponential notation · 156

else keyword · 171

extending a class during inheritance · 41

encapsulation · 261

extends · 260, 277, 342; and interface ·

Enterprise JavaBeans (EJB) · 990

359; keyword · 275

enum, groups of constant values in C &

extensible: program · 320

C++ · 359

extension: pure inheritance vs. extension ·

Enumeration · 520

341

equals( ) · 142, 475; and hashed data

extension, sign · 147

structures · 485; overriding for

extension, zero · 147

HashMap · 484; vs. == · 645

Externalizable · 620; alternative approach

equivalence: == · 141; object equivalence ·

to using · 626

141

Extreme Programming (XP) · 88, 1093

error: handling with exceptions · 531;

recovery · 568; reporting errors in book

· 23; standard error stream · 538

event: event-driven system · 394;

JavaBeans · 801; multicast · 796;

multicast event and JavaBeans · 854;

fail fast containers · 515

responding to a Swing event · 707;

false · 143

Swing event model · 794; unicast · 796

FeatureDescriptor · 818

event listener · 722; order of execution ·

Field, for reflection · 678

796

fields, initializing fields in interfaces · 361

event model, Swing · 722

FIFO · 472

event-driven programming · 707

file: characteristics of files · 578; File.list( )

events and listeners · 723

· 574; incomplete output files, errors

EventSetDescriptors · 808

and flushing · 599; JAR file · 245

evolution, in program development · 85

File · 582, 592, 655; class · 574

exception: and base-class constructors ·

file dialogs · 776

281; and constructors · 561; and

File Transfer Protocol (FTP) · 699

inheritance · 558, 566; catching an

FileDescriptor · 582

exception · 534; catching any exception ·

FileInputReader · 597

1104

FileInputStream · 582

FilenameFilter · 574, 653

FileNotFoundException · 565

garbage collection · 207, 210, 333; and

FileOutputStream · 583

cleanup · 283; and native method

FileReader · 563, 590

execution · 1073; forcing finalization ·

FileWriter · 590, 599

286; how the collector works · 215;

fillInStackTrace( ) · 545

order of object reclamation · 286;

FilterInputStream · 582

reachable objects · 495; setting

FilterOutputStream · 583

references to null to allow cleanup · 397

FilterReader · 591

generator · 443

FilterWriter · 591

generator object, to fill arrays and

final · 350; and efficiency · 302; and

containers · 416

private · 299; and static · 294; argument

get( ), ArrayList · 450, 456

· 298, 577; blank finals · 297; classes ·

get( ), HashMap · 481

301; data · 294; keyword · 294; method ·

getBeanInfo( ) · 805

316; methods · 299, 339; static

getBytes( ) · 598

primitives · 296; with object references ·

getClass( ) · 544, 674

295

getConstructor( ) · 737

finalize( ) · 207, 566; and inheritance ·

getConstructors( ) · 681

333; and super · 335; calling directly ·

getContentPane( ) · 695

210; order of finalization of objects · 336

getContents( ) · 792

finally · 283, 286; and constructors · 562;

getEventSetDescriptors( ) · 808

keyword · 552; pitfall · 557

getFloat( ) · 930

finding .class files during loading · 247

getInputStream( ) · 909

flat-file database · 932

getInt( ) · 930

flavor, clipboard · 790

getInterfaces( ) · 676

float, literal value marker(F) · 156

getMethodDescriptors( ) · 808

floating point: true and false · 144

getMethods( ) · 681

FlowLayout · 714

getModel( ) · 784

flushing output files · 599

getName( ) · 677, 808

focus traversal · 691

getOutputStream( ) · 909

folding, constant · 294

getPriority( ) · 878

for keyword · 173

getPropertyDescriptors( ) · 808

forName( ) · 664, 727

getPropertyType( ) · 808

FORTRAN · 156

getReadMethod( ) · 808

forward referencing · 222

getSelectedValues( ) · 753

Fowler, Martin · 72, 85, 1093

getState( ) · 765

framework: application framework and

getString( ) · 930

applets · 694; control framework and

getSuperclass( ) · 676

inner classes · 394

getTransferData( ) · 792

friendly · 243, 368; and interface · 350;

getTransferDataFlavors( ) · 792

and protected · 290; less accessible than

getWriteMethod( ) · 808

protected · 335

Glass, Robert · 1094

FTP: File Transfer Protocol (FTP) · 699

glue, in BoxLayout · 717

function: member function · 35; overriding

goto: lack of goto in Java · 177

· 42

graphical user interface (GUI) · 394, 689

functor · 575

graphics · 776

Graphics · 768

greater than (>) · 141

greater than or equal to (>=) · 141

GridBagLayout · 716

GridLayout · 715, 894

1105

CheckedInputStream · 606;

guarded region, in exception handling ·

CheckedOutputStream · 606; close( ) ·

535

597; compression library · 606; console

GUI: graphical user interface · 394, 689

input · 597; controlling the process of

GUI builders · 690

serialization · 619; DataInput · 593;

guidelines: object development · 83

DataInputStream · 586, 591, 597, 599;

guidelines, coding standards · 1077

DataOutput · 593; DataOutputStream ·

GZIPInputStream · 606

588, 592, 599; DeflaterOutputStream ·

GZIPOutputStream · 606

606; directory lister · 574; directory,

creating directories and paths · 578;

Externalizable · 620; File · 582, 592,

655; File class · 574; File.list( ) · 574;

FileDescriptor · 582; FileInputReader ·

handler, exception · 535

597; FileInputStream · 582;

hardware devices, interfacing with · 1065

FilenameFilter · 574, 653;

has-a · 37

FileOutputStream · 583; FileReader ·

has-a relationship, composition · 289

563, 590; FileWriter · 590, 599;

hash code · 477, 488

FilterInputStream · 582;

hash function · 488

FilterOutputStream · 583; FilterReader ·

hashCode( ) · 473, 477; and hashed data

591; FilterWriter · 591; from standard

structures · 485; issues when writing ·

input · 602; GZIPInputStream · 606;

492; overriding for HashMap · 484

GZIPOutputStream · 606;

hashing · 485; external chaining · 488;

InflaterInputStream · 606; input · 581;

perfect hashing function · 488

InputStream · 581, 913;

HashMap · 476, 500, 733; used with

InputStreamReader · 589, 590, 913;

ArrayList · 652

internationalization · 590; library · 573;

HashSet · 473, 506

lightweight persistence · 613;

Hashtable · 510, 521

LineNumberInputStream · 586;

hasNext( ), Iterator · 457

LineNumberReader · 591; mark( ) · 593;

Hexadecimal · 156

mkdirs( ) · 580; nextToken( ) · 654;

hiding: implementation · 35

ObjectOutputStream · 614; output · 581;

hiding, implementation · 261

OutputStream · 581, 583, 913;

high concept · 75

OutputStreamWriter · 589, 590, 913;

HTML · 948; name · 839; param · 839;

pipe · 581; piped stream · 869; piped

value · 839

streams · 602; PipedInputStream · 582;

HTML on Swing components · 779

PipedOutputStream · 582, 583;

PipedReader · 590; PipedWriter · 590;

PrintStream · 588; PrintWriter · 591,

599, 913; pushBack( ) · 654;

PushbackInputStream · 586;

I/O: and threads, blocking · 860;

PushBackReader · 591;

available( ) · 598; blocking on I/O · 869;

RandomAccessFile · 592, 593, 599;

blocking, and available( ) · 598;

read( ) · 581; readChar( ) · 600;

BufferedInputStream · 586;

readDouble( ) · 600; Reader · 581, 589,

BufferedOutputStream · 588;

590, 913; readExternal( ) · 620;

BufferedReader · 563, 591, 597;

readLine( ) · 565, 591, 599, 600, 603;

BufferedWriter · 591, 599;

readObject( ) · 614; redirecting standard

ByteArrayInputStream · 582;

I/O · 604; renameTo( ) · 580; reset( ) ·

ByteArrayOutputStream · 583;

593; seek( ) · 593, 601;

characteristics of files · 578;

SequenceInputStream · 582, 592;

CharArrayReader · 590;

Serializable · 620; setErr(PrintStream) ·

CharArrayWriter · 590;

604; setIn(InputStream) · 604;

1106

vs composition · 642; vs. composition ·

setOut(PrintStream) · 604;

294

StreamTokenizer · 591, 639, 653, 682;

initial capacity, of a HashMap or HashSet ·

StringBuffer · 582;

491

StringBufferInputStream · 582;

initialization: and class loading · 304;

StringReader · 590, 597; StringWriter ·

array initialization · 231; base class ·

590; System.err · 602; System.in · 597,

278; class member · 273; constructor

602; System.out · 602; transient · 624;

initialization during inheritance and

typical I/O configurations · 594;

composition · 281; initializing class

Unicode · 590; write( ) · 581;

members at point of definition · 221;

writeBytes( ) · 600; writeChars( ) · 600;

initializing with the constructor · 191;

writeDouble( ) · 600; writeExternal( ) ·

instance initialization · 229, 375;

620; writeObject( ) · 614; Writer · 581,

member initializers · 332; non-static

589, 590, 913; ZipEntry · 610;

instance initialization · 229; of class

ZipInputStream · 606;

data members · 220; of method

ZipOutputStream · 606

variables · 220; order of initialization ·

Icon · 738

223, 338; static · 306; with inheritance ·

IDL · 982

304

idltojava · 984

inizialization: lazy · 273

if-else statement · 151, 171

inline method calls · 299

IllegalMonitorStateException · 866

inner class · 365, 799; access rights · 376;

ImageIcon · 738

and super · 385; and overriding · 385;

immutable objects · 1047

and control frameworks · 394; and

implementation · 34; and interface · 288,

Swing · 722; and upcasting · 368;

350; and interface, separating · 36; and

anonymous · 709; anonymous inner

interface, separation · 262; hiding · 35,

class · 576, 875; anonymous inner class

261, 368; separation of interface and

and constructors · 375; anonymous, and

implementation · 722

table-driven code · 502; callback · 391;

implements keyword · 350

closure · 391; hidden reference to the

import keyword · 244

object of the enclosing class · 378;

increment operator · 139

identifiers and .class files · 387; in

incremental development · 291

methods & scopes · 370; inheriting from

indexed property · 818

inner classes · 384; nesting within any

indexing operator [ ] · 231

arbitrary scope · 372; private · 833;

indexOf( ): String · 576, 681

private inner classes · 397; referring to

InflaterInputStream · 606

the outer class object · 381; static inner

inheritance · 38, 260, 271, 275, 311; and

classes · 379

cloning · 1034; and final · 302; and

input: console input · 597

finalize( ) · 333; and synchronized · 858;

InputStream · 581, 913

choosing composition vs. inheritance ·

InputStreamReader · 589, 590, 913

288; class inheritance diagrams · 293;

insertNodeInto( ) · 784

combining composition & inheritance ·

instance: instance initialization · 375; non-

281; designing with inheritance · 339;

static instance initialization · 229

diagram · 47; extending a class during ·

instance of a class · 31

41; extending interfaces with

instanceof: dynamic instanceof · 671;

inheritance · 358; from an abstract class

keyword · 666

· 326; from inner classes · 384;

Integer: parseInt( ) · 776

inheritance and method overloading vs.

Integer wrapper class · 233

overriding · 286; initialization with

interface: and implementation, separation

inheritance · 304; multiple inheritance

· 262; and inheritance · 358; base-class

in C++ and Java · 354; pure inheritance

interface · 320; Cloneable interface used

vs. extension · 341; specialization · 289;

as a flag · 1022; common interface · 325;

1107

library · 440; public Java seminars · 11;

defining the class · 88; for an object ·

versions · 22

32; graphical user interface (GUI) · 394,

Java 1.1: I/O streams · 589

689; implementation, separation of · 36;

Java AWT · 689

initializing fields in interfaces · 361;

Java Foundation Classes (JFC/Swing) ·

keyword · 349; nesting interfaces within

689

classes and other interfaces · 362;

Java operators · 133

private, as nested interfaces · 364;

Java programs, running from the

Runnable · 836; separation of interface

Windows Explorer · 705

and implementation · 722; upcasting to

Java Server Pages (JSP) · 960

an interface · 353; user · 78; vs. abstract

Java Virtual Machine · 662

· 356; vs. implemenation · 288

JavaBeans: see Beans · 800

Interface Definition Language (IDL) · 982

javac · 121

interfaces: name collisions when

javah · 1067

combining interfaces · 356

JButton · 738

interfacing with hardware devices · 1065

JButton, Swing · 706

internationalization, in I/O library · 590

JCheckBox · 738, 748

Internet: Internet Protocol · 905; Internet

JCheckboxMenuItem · 765

Service Provider (ISP) · 699

JCheckBoxMenuItem · 760

interrupt( ) · 873

JComboBox · 751

InterruptedException · 827

JComponent · 740, 768

intranet · 693; and applets · 693

JDBC: createStatement( ) · 930; database

Introspector · 805

URL · 928; DatabaseMetaData · 938;

IP (Internet Protocol) · 905

executeQuery( ) · 930; flat-file database

is-a · 341; relationship, inheritance · 289;

· 932; getFloat( ) · 930; getInt( ) · 930;

relationship, inheritance & upcasting ·

getString( ) · 930; Java DataBase

292; vs. is-like-a relationships · 42

Connectivity · 927; join · 932; relational

isDaemon( ) · 840

database · 933; ResultSet · 930; SQL

isDataFlavorSupported( ) · 792

stored procedures · 935; Statement ·

isInstance · 671

930; Structured Query Language (SQL)

isInterface( ) · 677

· 927

is-like-a · 342

JDialog · 771; menus · 759

ISP (Internet Service Provider) · 699

JDK: downloading and installing · 121

iteration, in program development · 84

JFC: Java Foundation Classes

iterator · 456

(JFC/Swing) · 689

Iterator · 456, 463, 500; hasNext( ) · 457;

JFileChooser · 776

next( ) · 457

JFrame · 704, 713; menus · 759

iterator( ) · 463

Jini · 1003

JIT: Just-In Time compilers · 98

JLabel · 695, 743

JList · 753

JMenu · 759, 765

Jacobsen, Ivar · 1093

JMenuBar · 759, 766

JApplet · 713; menus · 759

JMenuItem · 738, 759, 765, 766, 768

JAR · 816; archive tag, for HTML and JAR

JNI functions · 1069

files · 793; file · 245; jar files and

JNICALL · 1068

classpath · 249; packaging applets to

JNIEnv · 1069

optimize loading · 793

JNIEXPORT · 1068

JAR utility · 611

join · 932

Java · 99; and pointers · 1013; and set-top

JOptionPane · 756

boxes · 146; capitalization style source-

JPanel · 713, 736, 768, 894

code checking tool · 645; compiling and

JPopupMenu · 766

running a program · 121; containers

1108

list boxes · 753

JProgressBar · 781

listener adapters · 729

JRadioButton · 738, 750

listener classes · 799

JScrollPane · 712, 744, 755, 784

listener interfaces · 728

JSlider · 781

listeners and events · 723

JSP · 960

Lister, Timothy · 1095

JTabbedPane · 755

ListIterator · 467

JTable · 784

literal: class literal · 664, 669; double · 156;

JTextArea · 711, 790

float · 156; long · 156; values · 155

JTextField · 708, 740

load factor, of a HashMap or HashSet · 491

JTextPane · 747

loading: .class files · 247; initialization &

JToggleButton · 736

class loading · 304; loding a class · 305

JTree · 781

local loopback IP address · 907

JVM (Java Virtual Machine) · 662

localhost · 907; and RMI · 977

lock, for multithreading · 848

logarithms: natural logarithms · 156

logical: AND · 154; operator and short-

circuiting · 144; operators · 143; OR ·

keyboard navigation, and Swing · 691

154

keyboard shortcuts · 765

long, literal value marker (L) · 156

keySet( ) · 511

Look & Feel: Pluggable · 787

keywords: class · 32, 38

lvalue · 134

Koenig, Andrew · 1079

main( ) · 277

label · 178

maintenance, program · 85

labeled break · 178

management obstacles · 95

labeled continue · 178

manifest file, for JAR files · 611, 816

late binding · 45, 311, 316

map · 477

layout: controlling layout with layout

Map · 408, 439, 440, 476, 508

managers · 712

Map.Entry · 486

lazy inizialization · 273

mark( ) · 593

left-shift operator (<<) · 147

Math.random( ) · 480; values produced by

length, array member · 232

· 186

length, for arrays · 409

mathematical operators · 137

less than (<) · 141

max( ) · 512

less than or equal to (<=) · 141

member: member function · 35; object · 37

lexicographic vs. alphabetic sorting · 436

member initializers · 332

library: creator, vs. client programmer ·

memory exhaustion, solution via

243; design · 243; use · 244

References · 495

LIFO · 471

mentoring: and training · 95, 96

lightweight: Swing components · 691

menu: JPopupMenu · 766

lightweight persistence · 613

menus: JDialog, JApplet, JFrame · 759

LineNumberInputStream · 586

message box, in Swing · 756

LineNumberReader · 591

message, sending · 33

linked list · 440

meta-class · 662

LinkedList · 467, 472, 505

method: adding more methods to a design

list: drop-down list · 751

· 268; aliasing during a method call ·

List · 408, 439, 440, 467, 753; sorting and

1014; aliasing during method calls · 136;

searching · 511

behavior of polymorphic methods inside

1109

name, HTML keyword · 839

constructors · 337; distinguishing

Naming: bind( ) · 976; rebind( ) · 978;

overloaded methods · 196; final · 316,

unbind( ) · 978

339; final methods · 299; initialization

narrowing conversion · 155, 170, 201

of method variables · 220; inline

native method interface (NMI) in Java 1.0

method calls · 299; inner classes in

· 1065

methods & scopes · 370; lookup tool ·

natural logarithms · 156

724; method call binding · 315;

nesting interfaces · 362

overloading · 194; passing a reference

network programming · 904; accept( ) ·

into a method · 1014; polymorphic

909; client · 907; Common-Gateway

method call · 311; private · 339;

Interface (CGI) · 948; datagrams · 923;

protected methods · 290; recursive ·

dedicated connection · 917; displaying a

459; static · 206; synchronized method

Web page from within an applet · 923;

and blocking · 860

DNS (Domain Name System) · 905;

Method · 808; for reflection · 678

dotted quad · 905; getInputStream( ) ·

MethodDescriptors · 808

909; getOutputStream( ) · 909; HTML ·

methodology, analysis and design · 71

948; identifying machines · 905;

Meyers, Scott · 35

Internet Protocol (IP) · 905; Java

Microsoft · 820; Visual Basic · 800

DataBase Connectivity (JDBC) · 927;

min( ) · 512

local loopback IP address · 907;

mission statement · 75

localhost · 907; multithreading · 917;

mistakes, and design · 268

port · 908; reliable protocol · 923;

mkdirs( ) · 580

server · 907; serving multiple clients ·

mnemonics (keyboard shortcuts) · 765

917; showDocument( ) · 924; Socket ·

modulus · 137

915; stream-based sockets · 923; testing

monitor, for multithreading · 848

programs without a network · 907;

multicast · 814; event, and JavaBeans ·

Transmission Control Protocol (TCP) ·

854; multicast events · 796

923; unreliable protocol · 923; URL ·

multidimensional arrays · 236

925; User Datagram Protocol (UDP) ·

Multimedia CD ROM for book · 20

923

multiparadigm programming · 31

new operator · 207; and primitives, array ·

multiple inheritance, in C++ and Java ·

233

354

newInstance( ) · 737; reflection · 676

multiplication · 137

next( ), Iterator · 457

multiply-nested class · 383

nextToken( ) · 654

MultiStringMap · 652

NMI: Java 1.0 native method interface ·

multitasking · 825

1065

multithreading · 825, 917; and containers ·

no-arg: constructors · 196

514; and JavaBeans · 854; blocking ·

non-Java code, calling · 1065

859; deadlock · 865; deciding what

North, BorderLayout · 713

methods to synchronize · 858;

NOT: logical (!) · 143

drawbacks · 899; Runnable · 891;

not equivalent (!=) · 141

servlets · 954; when to use it · 899

notify( ) · 860

multi-tiered systems · 796

notifyAll( ) · 860

notifyListeners( ) · 858

null · 107, 411; garbage collection, allowing

cleanup · 397

NullPointerException · 550

name · 697; clash · 244; collisions · 250;

numbers, binary · 156

creating unique package names · 247;

spaces · 244

name collisions when combining interfaces

· 356

1110

141; shift · 147; ternary · 151; unary · 139,

146

optional methods, in the Java 2 containers

object · 31; aliasing · 136; arrays are first-

· 516

class objects · 409; assigning objects by

OR · 154; (||) · 143

copying references · 134; assignment

order: of constructor calls with inheritance

and reference copying · 134; business

· 330; of finalization of objects · 336; of

object/logic · 796; Class object · 633,

initialization · 223, 304, 338

662, 848; creation · 192; equals( )

organization, code · 255

method · 142; equivalence · 141;

OutputStream · 581, 583, 913

equivalence vs reference equivalence ·

OutputStreamWriter · 589, 590, 913

142; final · 295; five stages of object

overflow: and primitive types · 169

design · 82; guidelines for object

overloading: and constructors · 194;

development · 83; immutable objects ·

distinguishing overloaded methods ·

1047; interface to · 32; lock, for

196; lack of name hiding during

multithreading · 848; member · 37;

inheritance · 286; method overloading ·

object-oriented programming · 660;

194; on return values · 202; operator +

order of finalization of objects · 336;

and += overloading for String · 277;

process of creation · 227; reference

operator overloading · 153; operator

equivalence vs. object equivalence ·

overloading for String · 1054;

1025; serialization · 613; web of objects ·

overloading vs. overriding · 286; vs.

614, 1020

overriding · 324

Object · 408; clone( ) · 1021, 1025;

overriding: and inner classes · 385;

getClass( ) · 674; hashCode( ) · 477;

function · 42; overloading vs. overriding

standard root class, default inheritance

· 286; vs. overloading · 324

from · 275; wait( ) and notify( ) methods

· 866

object-oriented: analysis and design · 71;

basic concepts of object-oriented

programming (OOP) · 29

package · 244; access, and friendly · 255;

ObjectOutputStream · 614

and applets · 699; and directory

obstacles, management · 95

structure · 254; creating unique package

Octal · 156

names · 247; default package · 257;

ODBC · 928

names, capitalization · 116; visibility,

OMG · 981

friendly · 368

ones complement operator · 146

paintComponent( ) · 768, 776

OOP · 262; analysis and design · 71; basic

Painting on a JPanel in Swing · 768

characteristics · 31; basic concepts of

pair programming · 90

object-oriented programming · 29;

paralysis, analysis · 72

protocol · 350; Simula programming

param, HTML keyword · 839

language · 32; substitutability · 31

parameter, applet · 697

operator · 133; + and += overloading for

parameterized type · 455

String · 277; +, for String · 1054; == and

parseInt( ) · 776

!= · 1025; binary · 146; bitwise · 146;

pass: pass by value · 1018; passing a

casting · 154; comma · 152; comma

reference into a method · 1014

operator · 175; common pitfalls · 153;

Pattern: Command Pattern · 575

indexing operator [ ] · 231; logical · 143;

patterns, design · 86, 94

logical operators and short-circuiting ·

patterns, design patterns · 266

144; ones-complement · 146; operator

perfect hashing function · 488

overloading for String · 1054;

performance: and final · 302

overloading · 153; precedence · 134;

performance issues · 96

precedence mnemonic · 158; relational ·

Perl programming language · 705

1111

programming: basic concepts of object-

persistence · 630; lightweight persistence ·

oriented programming (OOP) · 29;

613

coding standards · 1077; event-driven

PhantomReference · 495

programming · 707; Extreme

pipe · 581

Programming (XP) · 88, 1093; in the

piped stream · 869

large · 92; multiparadigm · 31; object-

piped streams · 602

oriented · 660; pair · 90

PipedInputStream · 582

progress bar · 780

PipedOutputStream · 582, 583

promotion: of primitive types · 169; type

PipedReader · 590

promotion · 157

PipedWriter · 590

Properties · 652

planning, software development · 74

property · 801; bound properties · 818;

Plauger, P.J. · 1094

constrained properties · 818; custom

Pluggable Look & Feel · 787

property editor · 818; custom property

pointer: Java exclusion of pointers · 391

sheet · 818; indexed property · 818

pointers, and Java · 1013

PropertyChangeEvent · 818

polymorphism · 44, 311, 346, 660, 685;

PropertyDescriptors · 808

and constructors · 330; behavior of

ProptertyVetoException · 818

polymorphic methods inside

protected · 36, 243, 255, 260, 290; and

constructors · 337

friendly · 290; is also friendly · 261;

port · 908

more accessible than friendly · 335; use

portability in C, C++ and Java · 158

in clone( ) · 1021

position, absolute, when laying out Swing

protocol · 350; unreliable protocol · 923

components · 716

prototyping: rapid · 86

precedence: operator precedence

public · 36, 243, 255, 256; and interface ·

mnemonic · 158

350; class, and compilation units · 245

prerequisites, for this book · 29

pure: substitution · 42

primitive: comparison · 142; containers of

pure inheritance, vs. extension · 341

primitives · 412; data types, and use

pure substitution · 342

with operators · 159; dealing with the

pushBack( ) · 654

immutability of primitive wrapper

PushbackInputStream · 586

classes · 1047; final · 294; final static

PushBackReader · 591

primitives · 296; initialization of class

put( ), HashMap · 481

data members · 220; wrappers · 481

Python · 81, 99

primitive types · 105

printInfo( ) · 677

printing arrays · 417

println( ) · 458

printStackTrace( ) · 543, 545

PrintStream · 588

queue · 440, 472

PrintWriter · 591, 599, 913

priority: default priority for a Thread

group · 882; thread · 877

private · 36, 243, 255, 258, 290, 848;

illusion of overriding private methods ·

RAD (Rapid Application Development) ·

299; inner class · 833; inner classes ·

678

397; interfaces, when nested · 364;

radio button · 750

methods · 339

random number generator, values

problem space · 30, 291

produced by · 186

process, and threading · 825

random( ) · 480

program: maintenance · 85

RandomAccessFile · 592, 593, 599

programmer, client · 35

rapid prototyping · 86

1112

RMI: AlreadyBoundException · 978; and

reachable objects and garbage collection ·

CORBA · 989; bind( ) · 976; localhost ·

495

977; rebind( ) · 978; Remote · 974;

read( ) · 581

remote interface · 974; Remote Method

readChar( ) · 600

Invocation · 973; remote object registry ·

readDouble( ) · 600

976; RemoteException · 974, 980; rmic ·

Reader · 581, 589, 590, 869, 913

979; rmic and classpath · 979;

readExternal( ) · 620

rmiregistry · 976; RMISecurityManager

reading from standard input · 602

· 976; Serializable arguments · 978;

readLine( ) · 565, 591, 599, 600, 603

skeleton · 978; stub · 978; TCP/IP · 977;

readObject( ) · 614; with Serializable · 627

unbind( ) · 978; UnicastRemoteObject ·

rebind( ) · 978

974

recursion, unintended via toString() · 459

rmic · 979

redirecting standard I/O · 604

rmiregistry · 976

refactoring · 85

RMISecurityManager · 976

reference: assigning objects by copying

rollover · 740

references · 134; equivalence vs object

RTTI: and cloning · 1025; cast · 661; Class ·

equivalence · 142; final · 295; finding

737; Class object · 662;

exact type of a base reference · 662; null

ClassCastException · 666; Constructor ·

· 107; reference equivalence vs. object

678; difference between RTTI and

equivalence · 1025

reflection · 679; downcast · 666; Field ·

Reference, from java.lang.ref · 495

678; getConstructor( ) · 737; instanceof

referencing, forward referencing · 222

keyword · 666; isInstance · 671; meta-

reflection · 677, 678, 724, 804; and Beans ·

class · 662; Method · 678;

801; difference between RTTI and

newInstance( ) · 737; reflection · 677;

reflection · 679

run-time type identification (RTTI) ·

reflection example · 736

344; type-safe downcast · 665; using the

registry: remote object registry · 976

Class object · 674

relational: database · 933; operators · 141

Rumbaugh, James · 1093

reliable protocol · 923

runFinalizersOnExit( ) · 335

Remote Method Invocation (RMI) · 973

Runnable · 891; interface · 836; Thread ·

RemoteException · 980

859

removeActionListener( ) · 812, 857

running a Java program · 121

removeXXXListener( ) · 723

run-time binding · 316; polymorphism ·

renameTo( ) · 580

311

reporting errors in book · 23

run-time type identification: (RTTI) · 344;

request, in OOP · 33

misuse · 685; shape example · 659;

requirements analysis · 75

when to use it · 685

reset( ) · 593

RuntimeException · 408, 550

ResultSet · 930

rvalue · 134

resume( ) · 860, 864; and deadlocks · 873;

deprecation in Java 2 · 875

resumption, termination vs. resumption,

exception handling · 536

re-throwing an exception · 545

return: an array · 413; constructor return

safety, and applet restrictions · 692

value · 193; overloading on return value

scenario · 77

· 202

scheduling · 79

reusability · 37

scope: inner class nesting within any

reuse · 83; code reuse · 271; existing class

arbitrary scope · 372; inner classes in

libraries · 94; reusable code · 800

methods & scopes · 370; use case · 84

right-shift operator (>>) · 147

scrolling in Swing · 712

searching: sorting and searching Lists · 511

1113

signed two's complement · 151

searching an array · 437

Simula programming language · 32

section, critical section and synchronized

Simula-67 · 262

block · 852

sine wave · 768

seek( ) · 593, 601

singleton: design pattern · 266

seminars: public Java seminars · 11;

size( ), ArrayList · 451

training, provided by Bruce Eckel · 23

Size, of a HashMap or HashSet · 491

sending a message · 33

sizeof( ): lack of in Java · 158

separating business logic from UI logic ·

skeleton, RMI · 978

796

sleep( ) · 827, 846, 860, 862

separation of interface and

slider · 780

implementation · 36, 262, 722

Smalltalk · 31, 207

SequenceInputStream · 582, 592

Socket · 915

Serializable · 613, 620, 625, 637, 814;

sockets, stream-based · 923

readObject( ) · 627; writeObject( ) · 627

SoftReference · 495

serialization: and object storage · 630; and

software: development methodology · 72

transient · 624; controlling the process

Software Development Conference · 10

of serialization · 619;

solution space · 30

defaultReadObject( ) · 629;

sorting · 431; and searching Lists · 511

defaultWriteObject( ) · 629; RMI

source code copyright notice · 20

arguments · 978; to perform deep

South, BorderLayout · 713

copying · 1032; Versioning · 630

space: problem · 30; solution · 30

server · 907

specialization · 289

servlet · 948; multithreading · 954;

specification: system specification · 75

running servlets with Tomcat · 960;

specification, exception · 542

session tracking · 955

specifier: access specifiers · 36, 243, 255

session: and JSP · 969

SQL: stored procedures · 935; Structured

session tracking, with servlets · 955

Query Language · 927

Set · 408, 439, 440, 473, 506

Stack · 471, 521

setActionCommand( ) · 765

standard input: Reading from standard

setBorder( ) · 743

input · 602

setContents( ) · 792

standards: coding standards · 22, 1077

setDaemon( ) · 840

startup costs · 95

setDefaultCloseOperation( ) · 704

stateChanged( ) · 771

setErr(PrintStream) · 604

statement: mission · 75

setIcon( ) · 740

Statement · 930

setIn(InputStream) · 604

static · 350; and final · 294; block · 228;

setLayout( ) · 713

clause · 664; construction clause · 228;

setMnemonic( ) · 765

data initialization · 225; final static

setOut(PrintStream) · 604

primitives · 296; initialization · 306;

setPriority( ) · 878

inner classes · 379; keyword · 206;

setToolTipText( ) · 740

method · 206; synchronized static · 848

shallow copy · 1019, 1027

STL: C++ · 440

shape: example · 39, 316; example, and

stop( ): and deadlocks · 873; deprecation

run-time type identification · 659

in Java 2 · 873

shift operators · 147

stored procedures in SQL · 935

short-circuit, and logical operators · 144

stream, I/O · 581

shortcut, keyboard · 765

stream-based sockets · 923

show( ) · 773

StreamTokenizer · 591, 639, 653, 682

showDocument( ) · 924

String: automatic type conversion · 454;

shuffle( ) · 512

class methods · 1052; concatenation

side effect · 133, 141, 202, 1016

with operator + · 153; immutability ·

sign extension · 147

1114

1052; indexOf( ) · 576, 681;

table-driven code, and anonymous inner

lexicographic vs. alphabetic sorting ·

classes · 502

436; methods · 1056; operator + · 454;

TCP, Transmission Control Protocol · 923

Operator + · 153; operator + and +=

TCP/IP, and RMI · 977

overloading · 277; toString( ) · 272, 452

template: in C++ · 455

StringBuffer · 582; methods · 1058

termination vs. resumption, exception

StringBufferInputStream · 582

handling · 536

ternary operator · 151

StringReader · 590, 597

StringSelection · 792

testing: automated · 89; Extreme

StringTokenizer · 642

Programming (XP) · 88; unit testing ·

StringWriter · 590

277

testing techniques · 381

struts, in BoxLayout · 717

stub, RMI · 978

this keyword · 203

style of creating classes · 262

Thread · 825, 827; and JavaBeans · 854;

and Runnable · 891; blocked · 859;

subobject · 278, 288

combined with main class · 834;

substitutability, in OOP · 31

daemon threads · 840; dead · 859;

substitution: principle · 42

deadlock · 872; deciding what methods

subtraction · 137

to synchronize · 858; destroy( ) · 877;

super · 280; and finalize( ) · 335; and inner

classes · 385

drawbacks · 899; getPriority( ) · 878;

super keyword · 278

I/O and threads, blocking · 860;

super.clone( ) · 1021, 1025, 1041

interrupt( ) · 873; isDaemon( ) · 840;

superclass · 278

new Thread · 859; notify( ) · 860;

suspend( ) · 860, 864; and deadlocks · 873;

notifyAll( ) · 860; order of execution of

deprecation in Java 2 · 875

threads · 831; priority · 877; properly

Swing · 689

suspending & resuming · 874; resume( )

Swing component examples · 734

· 860, 864; resume( ) , deprecation in

Swing components, using HTML with ·

Java 2 · 875; resume( ), and deadlocks ·

779

873; run( ) · 829; Runnable · 859;

Runnable interface · 836; setDaemon( )

Swing event model · 722, 794

switch keyword · 183

· 840; setPriority( ) · 878; sharing

limited resources · 842; sleep( ) · 846,

synchronized · 59, 848; and inheritance ·

858; and wait( ) & notify( ) · 866;

860, 862; start( ) · 830; states · 859;

containers · 514; deciding what methods

stop( ) , deprecation in Java 2 · 873;

to synchronize · 858; efficiency · 853;

stop( ), and deadlocks · 873; stopping ·

873; suspend( ) · 860, 864; suspend( ) ,

method, and blocking · 860; static ·

848; synchronized block · 852

deprecation in Java 2 · 875; suspend( ),

and deadlocks · 873; synchronized

system clipboard · 790

method and blocking · 860; thread

system specification · 75

System.arraycopy( ) · 429

group · 882; thread group, default

priority · 882; threads and efficiency ·

System.err · 538, 602

System.gc( ) · 213

828; wait( ) · 860, 866; when they can

System.in · 597, 602

be suspended · 847; when to use threads

System.out · 602

· 899; yield( ) · 860

System.out.println( ) · 458

throw keyword · 534

Throwable · 547; base class for Exception ·

System.runFinalization( ) · 213

543

throwing an exception · 533

time-critical code sections · 1065

toArray( ) · 511

token · 639

tabbed dialog · 755

Tokenizing · 639

table · 784

1115

updates of the book · 22

Tomcat, standard servlet container · 960

URL · 925

tool tips · 740

use case · 76; iteration · 84; scope · 84

TooManyListenersException · 796, 814

User Datagram Protocol (UDP) · 923

toString( ) · 272, 452, 458, 500

user interface · 78; and threads, for

training · 93; and mentoring · 95, 96

responsiveness · 831; responsive, with

training seminars provided by Bruce Eckel

threading · 826

· 23

Transferable · 792

transient keyword · 624

translation unit · 245

Transmission Control Protocol (TCP) · 923

tree · 781

value: preventing change at run-time · 294

TreeMap · 476, 510, 642

value, HTML keyword · 839

TreeSet · 473, 506

variable: defining a variable · 174;

true · 143

initialization of method variables · 220;

try · 286, 554; try block in exceptions · 535

variable argument lists (unknown

two's complement, signed · 151

quantity and type of arguments) · 235

type: base · 39; data type equivalence to

vector: of change · 86

class · 33; derived · 39; finding exact

Vector · 505, 519, 521

type of a base reference · 662;

vector of change · 397

parameterized type · 455; primitive ·

versioning, serialization · 630

105; primitive data types and use with

versions of Java · 22

operators · 159; type checking and

visibility, package visibility, (friendly) ·

arrays · 408; type safety in Java · 154;

368

type-safe downcast in run-time type

visual: programming · 800

identification · 665; weak typing · 45

Visual Basic, Microsoft · 800

TYPE field, for primitive class literals · 665

visual programming environments · 690

type safe sets of constants · 361

type-conscious ArrayList · 454

wait( ) · 860, 866

Waldrop, M. Mitchell · 1095

UDP, User Datagram Protocol · 923

weak: weakly typed language · 45

UML · 81; indicating composition · 37;

WeakHashMap · 498

Unified Modeling Language · 35, 1093

WeakReference · 495

unary: minus (-) · 139; operator · 146;

Web: displaying a Web page from within

operators · 139; plus (+) · 139

an applet · 923; placing an applet inside

unbind( ) · 978

a Web page · 695; safety, and applet

unicast · 814; unicast events · 796

restrictions · 692

UnicastRemoteObject · 974

web of objects · 614, 1020

Unicode · 590

West, BorderLayout · 713

Unified Modeling Language (UML) · 35,

while · 172

1093

widening conversion · 155

unit testing · 277

wild-card · 73

unmodifiable, making a Collection or Map

WindowAdapter · 704

unmodifiable · 513

windowClosing( ) · 704, 771

unsupported methods, in the Java 2

windowed applications · 700

containers · 516

Windows Explorer, running Java

UnsupportedOperationException · 516

programs from · 705

upcasting · 47, 291, 312, 660; and interface

· 353; inner classes and upcasting · 368

1116

wrapper, dealing with the immutability of

primitive wrapper classes · 1047

write( ) · 581

yield( ) · 860

writeBytes( ) · 600

writeChars( ) · 600

writeDouble( ) · 600

writeExternal( ) · 620

writeObject( ) · 614; with Serializable · 627

Writer · 581, 589, 590, 869, 913

zero extension · 147

ZipEntry · 610

ZipInputStream · 606

ZipOutputStream · 606

XOR · 146

XP, Extreme Programming · 88

1117

Check

for in-depth details

and the date and location

of the next

Hands-On Java Seminar

· Based on this book

· Taught by Bruce Eckel

· Personal attention from Bruce Eckel

and his seminar assistants

· Includes in-class programming exercises

· Intermediate/Advanced seminars also offered

· Hundreds have already enjoyed this seminar--

see the Web site for their testimonials

1118

Bruce Eckel's Hands-On Java Seminar

Multimedia CD

It's like coming to the seminar!

Available at

! The Hands-On Java Seminar captured on a Multimedia CD!

! Overhead slides and synchronized audio voice narration for all

the lectures. Just play it to see and hear the lectures!

! Created and narrated by Bruce Eckel.

! Based on the material in this book.

Demo lecture available at

1119

End-User License Agreement for Microsoft Software

IMPORTANT-READ CAREFULLY: This Microsoft End-User License Agreement

("EULA") is a legal agreement between you (either an individual or a single

entity) and Microsoft Corporation for the Microsoft software product included in

this package, which includes computer software and may include associated

media, printed materials, and "online" or electronic documentation

("SOFTWARE PRODUCT"). The SOFTWARE PRODUCT also includes any updates

and supplements to the original SOFTWARE PRODUCT provided to you by

Microsoft. By installing, copying, downloading, accessing or otherwise using

the SOFTWARE PRODUCT, you agree to be bound by the terms of this EULA. If

you do not agree to the terms of this EULA, do not install, copy, or otherwise

use the SOFTWARE PRODUCT.

SOFTWARE PRODUCT LICENSE

The SOFTWARE PRODUCT is protected by copyright laws and international

SOFTWARE PRODUCT is licensed, not sold.

1. GRANT OF LICENSE. This EULA grants you the following rights:

1.1 License Grant. Microsoft grants to you as an individual, a personal

nonexclusive license to make and use copies of the SOFTWARE PRODUCT for

the sole purposes of evaluating and learning how to use the SOFTWARE

PRODUCT, as may be instructed in accompanying publications or

documentation. You may install the software on an unlimited number of

computers provided that you are the only individual using the SOFTWARE

PRODUCT.

1.2 Academic Use. You must be a "Qualified Educational User" to use the

SOFTWARE PRODUCT in the manner described in this section. To determine

whether you are a Qualified Educational User, please contact the Microsoft

Sales Information Center/One Microsoft Way/Redmond, WA 98052-6399 or the

Microsoft subsidiary serving your country. If you are a Qualified Educational

User, you may either:

(i) exercise the rights granted in Section 1.1, OR

(ii) if you intend to use the SOFTWARE PRODUCT solely for instructional

purposes in connection with a class or other educational program, this EULA

grants you the following alternative license models:

(A) Per Computer Model. For every valid license you have acquired for the

SOFTWARE PRODUCT, you may install a single copy of the SOFTWARE

PRODUCT on a single computer for access and use by an unlimited number of

1120

student end users at your educational institution, provided that all such end

users comply with all other terms of this EULA, OR

(B) Per License Model. If you have multiple licenses for the SOFTWARE

PRODUCT, then at any time you may have as many copies of the SOFTWARE

PRODUCT in use as you have licenses, provided that such use is limited to

student or faculty end users at your educational institution and provided that

all such end users comply with all other terms of this EULA. For purposes of

this subsection, the SOFTWARE PRODUCT is "in use" on a computer when it is

loaded into the temporary memory (i.e., RAM) or installed into the permanent

memory (e.g., hard disk, CD ROM, or other storage device) of that computer,

except that a copy installed on a network server for the sole purpose of

distribution to other computers is not "in use". If the anticipated number of

users of the SOFTWARE PRODUCT will exceed the number of applicable

licenses, then you must have a reasonable mechanism or process in place to

ensure that the number of persons using the SOFTWARE PRODUCT

concurrently does not exceed the number of licenses.

2. DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS.

· Limitations on Reverse Engineering, Decompilation, and Disassembly. You

may not reverse engineer, decompile, or disassemble the SOFTWARE

PRODUCT, except and only to the extent that such activity is expressly

permitted by applicable law notwithstanding this limitation.

· Separation of Components. The SOFTWARE PRODUCT is licensed as a single

product. Its component parts may not be separated for use on more than one

computer.

· Rental. You may not rent, lease or lend the SOFTWARE PRODUCT.

· Trademarks. This EULA does not grant you any rights in connection with any

trademarks or service marks of Microsoft.

· Software Transfer. The initial user of the SOFTWARE PRODUCT may make a

one-time permanent transfer of this EULA and SOFTWARE PRODUCT only

directly to an end user. This transfer must include all of the SOFTWARE

PRODUCT (including all component parts, the media and printed materials, any

upgrades, this EULA, and, if applicable, the Certificate of Authenticity). Such

transfer may not be by way of consignment or any other indirect transfer. The

transferee of such one-time transfer must agree to comply with the terms of

this EULA, including the obligation not to further transfer this EULA and

SOFTWARE PRODUCT.

· No Support. Microsoft shall have no obligation to provide any product

support for the SOFTWARE PRODUCT.

· Termination. Without prejudice to any other rights, Microsoft may terminate

this EULA if you fail to comply with the terms and conditions of this EULA. In

1121

such event, you must destroy all copies of the SOFTWARE PRODUCT and all of

its component parts.

3. COPYRIGHT. All title and intellectual property rights in and to the

SOFTWARE PRODUCT (including but not limited to any images, photographs,

animations, video, audio, music, text, and "applets" incorporated into the

SOFTWARE PRODUCT), the accompanying printed materials, and any copies of

the SOFTWARE PRODUCT are owned by Microsoft or its suppliers. All title and

intellectual property rights in and to the content which may be accessed

through use of the SOFTWARE PRODUCT is the property of the respective

content owner and may be protected by applicable copyright or other

intellectual property laws and treaties. This EULA grants you no rights to use

such content. All rights not expressly granted are reserved by Microsoft.

4. BACKUP COPY. After installation of one copy of the SOFTWARE PRODUCT

pursuant to this EULA, you may keep the original media on which the

SOFTWARE PRODUCT was provided by Microsoft solely for backup or archival

purposes. If the original media is required to use the SOFTWARE PRODUCT on

the COMPUTER, you may make one copy of the SOFTWARE PRODUCT solely

for backup or archival purposes. Except as expressly provided in this EULA,

you may not otherwise make copies of the SOFTWARE PRODUCT or the printed

materials accompanying the SOFTWARE PRODUCT.

5. U.S. GOVERNMENT RESTRICTED RIGHTS. The SOFTWARE PRODUCT and

documentation are provided with RESTRICTED RIGHTS. Use, duplication, or

disclosure by the Government is subject to restrictions as set forth in

subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software

clause at DFARS 252.227-7013 or subparagraphs (c)(1) and (2) of the

Commercial Computer Software-Restricted Rights at 48 CFR 52.227-19, as

applicable. Manufacturer is Microsoft Corporation/One Microsoft

Way/Redmond, WA 98052-6399.

6. EXPORT RESTRICTIONS. You agree that you will not export or re-export the

SOFTWARE PRODUCT, any part thereof, or any process or service that is the

direct product of the SOFTWARE PRODUCT (the foregoing collectively referred

to as the "Restricted Components"), to any country, person, entity or end user

subject to U.S. export restrictions. You specifically agree not to export or re-

export any of the Restricted Components (i) to any country to which the U.S.

has embargoed or restricted the export of goods or services, which currently

include, but are not necessarily limited to Cuba, Iran, Iraq, Libya, North Korea,

Sudan and Syria, or to any national of any such country, wherever located,

who intends to transmit or transport the Restricted Components back to such

country; (ii) to any end-user who you know or have reason to know will utilize

the Restricted Components in the design, development or production of

nuclear, chemical or biological weapons; or (iii) to any end-user who has been

1122

prohibited from participating in U.S. export transactions by any federal agency

of the U.S. government. You warrant and represent that neither the BXA nor

any other U.S. federal agency has suspended, revoked, or denied your export

privileges.

7. NOTE ON JAVA SUPPORT. THE SOFTWARE PRODUCT MAY CONTAIN

SUPPORT FOR PROGRAMS WRITTEN IN JAVA. JAVA TECHNOLOGY IS NOT

FAULT TOLERANT AND IS NOT DESIGNED, MANUFACTURED, OR INTENDED

FOR USE OR RESALE AS ON-LINE CONTROL EQUIPMENT IN HAZARDOUS

ENVIRONMENTS REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN THE

OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR

COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE SUPPORT

MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF JAVA

TECHNOLOGY COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR

SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE.

MISCELLANEOUS

If you acquired this product in the United States, this EULA is governed by the

laws of the State of Washington.

If you acquired this product in Canada, this EULA is governed by the laws of

the Province of Ontario, Canada. Each of the parties hereto irrevocably attorns

to the jurisdiction of the courts of the Province of Ontario and further agrees to

commence any litigation which may arise hereunder in the courts located in

the Judicial District of York, Province of Ontario.

If this product was acquired outside the United States, then local law may

apply.

Should you have any questions concerning this EULA, or if you desire to

contact Microsoft for any reason, please contact

Microsoft, or write: Microsoft Sales Information Center/One Microsoft

Way/Redmond, WA 98052-6399.

LIMITED WARRANTY

LIMITED WARRANTY. Microsoft warrants that (a) the SOFTWARE PRODUCT will

perform substantially in accordance with the accompanying written materials

for a period of ninety (90) days from the date of receipt, and (b) any Support

Services provided by Microsoft shall be substantially as described in applicable

written materials provided to you by Microsoft, and Microsoft support

engineers will make commercially reasonable efforts to solve any problem. To

the extent allowed by applicable law, implied warranties on the SOFTWARE

PRODUCT, if any, are limited to ninety (90) days. Some states/jurisdictions do

1123

not allow limitations on duration of an implied warranty, so the above

limitation may not apply to you.

CUSTOMER REMEDIES. Microsoft's and its suppliers' entire liability and your

exclusive remedy shall be, at Microsoft's option, either (a) return of the price

paid, if any, or (b) repair or replacement of the SOFTWARE PRODUCT that

does not meet Microsoft's Limited Warranty and that is returned to Microsoft

with a copy of your receipt. This Limited Warranty is void if failure of the

SOFTWARE PRODUCT has resulted from accident, abuse, or misapplication.

Any replacement SOFTWARE PRODUCT will be warranted for the remainder of

the original warranty period or thirty (30) days, whichever is longer. Outside

the United States, neither these remedies nor any product support services

offered by Microsoft are available without proof of purchase from an authorized

international source.

NO OTHER WARRANTIES. TO THE MAXIMUM EXTENT PERMITTED BY

APPLICABLE LAW, MICROSOFT AND ITS SUPPLIERS DISCLAIM ALL OTHER

WARRANTIES AND CONDITIONS, EITHER EXPRESS OR IMPLIED, INCLUDING,

BUT NOT LIMITED TO, IMPLIED WARRANTIES OR CONDITIONS OF

MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-

INFRINGEMENT, WITH REGARD TO THE SOFTWARE PRODUCT, AND THE

PROVISION OF OR FAILURE TO PROVIDE SUPPORT SERVICES. THIS LIMITED

WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY HAVE OTHERS,

WHICH VARY FROM STATE/JURISDICTION TO STATE/JURISDICTION.

LIMITATION OF LIABILITY. TO THE MAXIMUM EXTENT PERMITTED BY

APPLICABLE LAW, IN NO EVENT SHALL MICROSOFT OR ITS SUPPLIERS BE

LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL

DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR

LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS

INFORMATION, OR ANY OTHER PECUNIARY LOSS) ARISING OUT OF THE USE

OF OR INABILITY TO USE THE SOFTWARE PRODUCT OR THE FAILURE TO

PROVIDE SUPPORT SERVICES, EVEN IF MICROSOFT HAS BEEN ADVISED OF

THE POSSIBILITY OF SUCH DAMAGES. IN ANY CASE, MICROSOFT'S ENTIRE

LIABILITY UNDER ANY PROVISION OF THIS EULA SHALL BE LIMITED TO THE

GREATER OF THE AMOUNT ACTUALLY PAID BY YOU FOR THE SOFTWARE

PRODUCT OR U.S.$5.00; PROVIDED, HOWEVER, IF YOU HAVE ENTERED INTO

A MICROSOFT SUPPORT SERVICES AGREEMENT, MICROSOFT'S ENTIRE

LIABILITY REGARDING SUPPORT SERVICES SHALL BE GOVERNED BY THE

TERMS OF THAT AGREEMENT. BECAUSE SOME STATES/JURISDICTIONS DO

NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY, THE ABOVE

LIMITATION MAY NOT APPLY TO YOU.

0495 Part No. 64358

1124

LICENSE AGREEMENT FOR MindView, Inc.'s

Thinking in C: Foundations for Java & C++ CD ROM

by Chuck Allison

This CD is provided together with the book "Thinking in Java, 2nd edition."

READ THIS AGREEMENT BEFORE USING THIS "Thinking in C: Foundations for

C++ & Java" (Hereafter called "CD"). BY USING THE CD YOU AGREE TO BE

BOUND BY THE TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU DO

NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT,

IMMEDIATELY RETURN THE UNUSED CD FOR A FULL REFUND OF MONIES

PAID, IF ANY.

SOFTWARE REQUIREMENTS

The purpose of this CD is to provide the Content, not the associated software

necessary to view the Content. The Content of this CD is in HTML for viewing

with Microsoft Internet Explorer 4 or newer, and uses Microsoft Sound Codecs

available in Microsoft's Windows Media Player for Windows. It is your

responsibility to correctly install the appropriate Microsoft software for your

system.

The text, images, and other media included on this CD ("Content") and their

compilation are licensed to you subject to the terms and conditions of this

Agreement by MindView, Inc., having a place of business at 5343 Valle Vista,

La Mesa, CA 91941. Your rights to use other programs and materials included

on the CD are also governed by separate agreements distributed with those

programs and materials on the CD (the "Other Agreements"). In the event of

any inconsistency between this Agreement and the Other Agreements, this

Agreement shall govern. By using this CD, you agree to be bound by the terms

and conditions of this Agreement. MindView, Inc. owns title to the Content and

to all intellectual property rights therein, except insofar as it contains materials

that are proprietary to third-party suppliers. All rights in the Content except

those expressly granted to you in this Agreement are reserved to MindView,

Inc. and such suppliers as their respective interests may appear.

1. LIMITED LICENSE

MindView, Inc. grants you a limited, nonexclusive, nontransferable license to

use the Content on a single dedicated computer (excluding network servers).

This Agreement and your rights hereunder shall automatically terminate if you

fail to comply with any provisions of this Agreement or any of the Other

Agreements. Upon such termination, you agree to destroy the CD and all

copies of the CD, whether lawful or not, that are in your possession or under

your control.

2. ADDITIONAL RESTRICTIONS

a. You shall not (and shall not permit other persons or entities to) directly or

indirectly, by electronic or other means, reproduce (except for archival

purposes as permitted by law), publish, distribute, rent, lease, sell, sublicense,

assign, or otherwise transfer the Content or any part thereof.

b. You shall not (and shall not permit other persons or entities to) use the

Content or any part thereof for any commercial purpose or merge, modify,

create derivative works of, or translate the Content.

c. You shall not (and shall not permit other persons or entities to) obscure

MindView's or its suppliers copyright, trademark, or other proprietary notices

or legends from any portion of the Content or any related materials.

3. PERMISSIONS

a. Except as noted in the Contents of the CD, you must treat this software just

like a book. However, you may copy it onto a computer to be used and you

may make archival copies of the software for the sole purpose of backing up

the software and protecting your investment from loss. By saying, "just like a

book," MindView, Inc. means, for example, that this software may be used by

any number of people and may be freely moved from one computer location to

another, so long as there is no possibility of its being used at one location or

on one computer while it is being used at another. Just as a book cannot be

read by two different people in two different places at the same time, neither

can the software be used by two different people in two different places at the

same time.

b. You may show or demonstrate the un-modified Content in a live

presentation, live seminar, or live performance as long as you attribute all

material of the Content to MindView, Inc.

c. Other permissions and grants of rights for use of the CD must be obtained

directly from MindView, Inc. at http://www.MindView.net. (Bulk copies of the

CD may also be purchased at this site.)

DISCLAIMER OF WARRANTY

The Content and CD are provided "AS IS" without warranty of any kind, either

express or implied, including, without limitation, any warranty of

merchantability and fitness for a particular purpose. The entire risk as to the

results and performance of the CD and Content is assumed by you. MindView,

Inc. and its suppliers assume no responsibility for defects in the CD, the

accuracy of the Content, or omissions in the CD or the Content. MindView, Inc.

and its suppliers do not warrant, guarantee, or make any representations

regarding the use, or the results of the use, of the product in terms of

correctness, accuracy, reliability, currentness, or otherwise, or that the Content

will meet your needs, or that operation of the CD will be uninterrupted or

error-free, or that any defects in the CD or Content will be corrected.

MindView, Inc. and its suppliers shall not be liable for any loss, damages, or

costs arising from the use of the CD or the interpretation of the Content. Some

states do not allow exclusion or limitation of implied warranties or limitation of

liability for incidental or consequential damages, so all of the above limitations

or exclusions may not apply to you.

In no event shall MindView, Inc. or its suppliers' total liability to you for all

damages, losses, and causes of action (whether in contract, tort, or otherwise)

exceed the amount paid by you for the CD.

MindView, Inc., and Prentice-Hall, Inc. specifically disclaim the implied

warrantees of merchantability and fitness for a particular purpose. No oral or

written information or advice given by MindView, Inc., Prentice-Hall, Inc., their

dealers, distributors, agents or employees shall create a warrantee. You may

have other rights, which vary from state to state.

Neither MindView, Inc., Bruce Eckel, Chuck Allison, Prentice-Hall, nor anyone

else who has been involved in the creation, production or delivery of the

product shall be liable for any direct, indirect, consequential, or incidental

damages (including damages for loss of business profits, business interruption,

loss of business information, and the like) arising out of the use of or inability

to use the product even if MindView, Inc., has been advised of the possibility

of such damages. Because some states do not allow the exclusion or limitation

of liability for consequential or incidental damages, the above limitation may

not apply to you.

This CD is provided as a supplement to the book "Thinking in Java 2nd

edition." The sole responsibility of Prentice-Hall will be to provide a

replacement CD in the event that the one that came with the book is

defective. This replacement warrantee shall be in effect for a period of sixty

days from the purchase date. MindView, Inc. does not bear any additional

responsibility for the CD.

NO TECHNICAL SUPPORT IS PROVIDED WITH THIS CD ROM

The following are trademarks of their respective companies in the U.S. and

may be protected as trademarks in other countries: Sun and the Sun Logo,

1127

Sun Microsystems, Java, all Java-based names and logos and the Java Coffee

Cup are trademarks of Sun Microsystems; Internet Explorer, the Windows

Media Player, DOS, Windows 95, and Windows NT are trademarks of Microsoft.

Thinking in C: Foundations for Java & C++

Multimedia Seminar-on-CD ROM

WARNING: BEFORE OPENING THE DISC PACKAGE, CAREFULLY

READ THE TERMS AND CONDITIONS OF THE LICENSE

AGREEMENT & WARANTEE LIMITATION ON THE PREVIOUS

PAGES.

The CD ROM packaged with this book is a multimedia seminar consisting

of synchronized slides and audio lectures. The goal of this seminar is to

introduce you to the aspects of C that are necessary for you to move on to

C++ or Java, leaving out the unpleasant parts that C programmers must

deal with on a day-to-day basis but that the C++ and Java languages steer

you away from. The CD also contains this book in HTML form along with

the source code for the book.

This CD ROM will work with Windows (with a sound system). However,

you must:

1. Install the most recent version of Microsoft's Internet Explorer.

Because of the features provided on the CD, it will NOT work

with Netscape Navigator. The Internet Explorer software

for Windows 9X/NT is included on the CD.

2. Install Microsoft's Windows Media Player. The Media Player

software for Windows 9X/NT is included on the CD.

You can also go to

http://www.microsoft.com/windows/mediaplayer and

follow the instructions or links there to download and install the

Media Player for your particular platform.

3. At this point you should be able to play the lectures on the CD.

Using the Internet Explorer Web browser, open the file

Install.html that you'll find on the CD. This will introduce you

to the CD and provide further instructions about the use of the

CD.

1129

Table of Contents: