- •Preface
- •1.1 Machine Language
- •1.3 The Java Virtual Machine
- •1.4 Building Blocks of Programs
- •1.5 Object-oriented Programming
- •1.6 The Modern User Interface
- •Quiz on Chapter 1
- •2 Names and Things
- •2.1 The Basic Java Application
- •2.2.1 Variables
- •2.2.2 Types and Literals
- •2.2.3 Variables in Programs
- •2.3.2 Operations on Strings
- •2.3.3 Introduction to Enums
- •2.4 Text Input and Output
- •2.4.1 A First Text Input Example
- •2.4.2 Text Output
- •2.4.3 TextIO Input Functions
- •2.4.4 Formatted Output
- •2.4.5 Introduction to File I/O
- •2.5 Details of Expressions
- •2.5.1 Arithmetic Operators
- •2.5.2 Increment and Decrement
- •2.5.3 Relational Operators
- •2.5.4 Boolean Operators
- •2.5.5 Conditional Operator
- •2.5.7 Type Conversion of Strings
- •2.5.8 Precedence Rules
- •2.6 Programming Environments
- •2.6.1 Java Development Kit
- •2.6.2 Command Line Environment
- •2.6.3 IDEs and Eclipse
- •2.6.4 The Problem of Packages
- •Exercises for Chapter 2
- •Quiz on Chapter 2
- •3 Control
- •3.1 Blocks, Loops, and Branches
- •3.1.1 Blocks
- •3.1.2 The Basic While Loop
- •3.1.3 The Basic If Statement
- •3.2 Algorithm Development
- •3.2.2 The 3N+1 Problem
- •3.2.3 Coding, Testing, Debugging
- •3.3.1 The while Statement
- •3.3.2 The do..while Statement
- •3.3.3 break and continue
- •3.4 The for Statement
- •3.4.1 For Loops
- •3.4.2 Example: Counting Divisors
- •3.4.3 Nested for Loops
- •3.5 The if Statement
- •3.5.1 The Dangling else Problem
- •3.5.2 The if...else if Construction
- •3.5.3 If Statement Examples
- •3.5.4 The Empty Statement
- •3.6 The switch Statement
- •3.6.1 The Basic switch Statement
- •3.6.2 Menus and switch Statements
- •3.6.3 Enums in switch Statements
- •3.7.1 Exceptions
- •3.7.2 try..catch
- •3.7.3 Exceptions in TextIO
- •Exercises for Chapter 3
- •Quiz on Chapter 3
- •4 Subroutines
- •4.1 Black Boxes
- •4.2.2 Calling Subroutines
- •4.2.3 Subroutines in Programs
- •4.2.4 Member Variables
- •4.3 Parameters
- •4.3.1 Using Parameters
- •4.3.2 Formal and Actual Parameters
- •4.3.3 Overloading
- •4.3.4 Subroutine Examples
- •4.3.5 Throwing Exceptions
- •4.3.6 Global and Local Variables
- •4.4 Return Values
- •4.4.1 The return statement
- •4.4.2 Function Examples
- •4.4.3 3N+1 Revisited
- •4.5 APIs, Packages, and Javadoc
- •4.5.1 Toolboxes
- •4.5.3 Using Classes from Packages
- •4.5.4 Javadoc
- •4.6 More on Program Design
- •4.6.1 Preconditions and Postconditions
- •4.6.2 A Design Example
- •4.6.3 The Program
- •4.7 The Truth About Declarations
- •4.7.1 Initialization in Declarations
- •4.7.2 Named Constants
- •4.7.3 Naming and Scope Rules
- •Exercises for Chapter 4
- •Quiz on Chapter 4
- •5 Objects and Classes
- •5.1.1 Objects, Classes, and Instances
- •5.1.2 Fundamentals of Objects
- •5.1.3 Getters and Setters
- •5.2 Constructors and Object Initialization
- •5.2.1 Initializing Instance Variables
- •5.2.2 Constructors
- •5.2.3 Garbage Collection
- •5.3 Programming with Objects
- •5.3.2 Wrapper Classes and Autoboxing
- •5.4 Programming Example: Card, Hand, Deck
- •5.4.1 Designing the classes
- •5.4.2 The Card Class
- •5.4.3 Example: A Simple Card Game
- •5.5.1 Extending Existing Classes
- •5.5.2 Inheritance and Class Hierarchy
- •5.5.3 Example: Vehicles
- •5.5.4 Polymorphism
- •5.5.5 Abstract Classes
- •5.6 this and super
- •5.6.1 The Special Variable this
- •5.6.2 The Special Variable super
- •5.6.3 Constructors in Subclasses
- •5.7 Interfaces, Nested Classes, and Other Details
- •5.7.1 Interfaces
- •5.7.2 Nested Classes
- •5.7.3 Anonymous Inner Classes
- •5.7.5 Static Import
- •5.7.6 Enums as Classes
- •Exercises for Chapter 5
- •Quiz on Chapter 5
- •6 Introduction to GUI Programming
- •6.1 The Basic GUI Application
- •6.1.1 JFrame and JPanel
- •6.1.2 Components and Layout
- •6.1.3 Events and Listeners
- •6.2 Applets and HTML
- •6.2.1 JApplet
- •6.2.2 Reusing Your JPanels
- •6.2.3 Basic HTML
- •6.2.4 Applets on Web Pages
- •6.3 Graphics and Painting
- •6.3.1 Coordinates
- •6.3.2 Colors
- •6.3.3 Fonts
- •6.3.4 Shapes
- •6.3.5 Graphics2D
- •6.3.6 An Example
- •6.4 Mouse Events
- •6.4.1 Event Handling
- •6.4.2 MouseEvent and MouseListener
- •6.4.3 Mouse Coordinates
- •6.4.4 MouseMotionListeners and Dragging
- •6.4.5 Anonymous Event Handlers
- •6.5 Timer and Keyboard Events
- •6.5.1 Timers and Animation
- •6.5.2 Keyboard Events
- •6.5.3 Focus Events
- •6.5.4 State Machines
- •6.6 Basic Components
- •6.6.1 JButton
- •6.6.2 JLabel
- •6.6.3 JCheckBox
- •6.6.4 JTextField and JTextArea
- •6.6.5 JComboBox
- •6.6.6 JSlider
- •6.7 Basic Layout
- •6.7.1 Basic Layout Managers
- •6.7.2 Borders
- •6.7.3 SliderAndComboBoxDemo
- •6.7.4 A Simple Calculator
- •6.7.5 Using a null Layout
- •6.7.6 A Little Card Game
- •6.8 Menus and Dialogs
- •6.8.1 Menus and Menubars
- •6.8.2 Dialogs
- •6.8.3 Fine Points of Frames
- •6.8.4 Creating Jar Files
- •Exercises for Chapter 6
- •Quiz on Chapter 6
- •7 Arrays
- •7.1 Creating and Using Arrays
- •7.1.1 Arrays
- •7.1.2 Using Arrays
- •7.1.3 Array Initialization
- •7.2 Programming With Arrays
- •7.2.1 Arrays and for Loops
- •7.2.3 Array Types in Subroutines
- •7.2.4 Random Access
- •7.2.5 Arrays of Objects
- •7.2.6 Variable Arity Methods
- •7.3 Dynamic Arrays and ArrayLists
- •7.3.1 Partially Full Arrays
- •7.3.2 Dynamic Arrays
- •7.3.3 ArrrayLists
- •7.3.4 Parameterized Types
- •7.3.5 Vectors
- •7.4 Searching and Sorting
- •7.4.1 Searching
- •7.4.2 Association Lists
- •7.4.3 Insertion Sort
- •7.4.4 Selection Sort
- •7.4.5 Unsorting
- •7.5.3 Example: Checkers
- •Exercises for Chapter 7
- •Quiz on Chapter 7
- •8 Correctness and Robustness
- •8.1 Introduction to Correctness and Robustness
- •8.1.1 Horror Stories
- •8.1.2 Java to the Rescue
- •8.1.3 Problems Remain in Java
- •8.2 Writing Correct Programs
- •8.2.1 Provably Correct Programs
- •8.2.2 Robust Handling of Input
- •8.3 Exceptions and try..catch
- •8.3.1 Exceptions and Exception Classes
- •8.3.2 The try Statement
- •8.3.3 Throwing Exceptions
- •8.3.4 Mandatory Exception Handling
- •8.3.5 Programming with Exceptions
- •8.4 Assertions
- •8.5 Introduction to Threads
- •8.5.1 Creating and Running Threads
- •8.5.2 Operations on Threads
- •8.5.4 Wait and Notify
- •8.5.5 Volatile Variables
- •8.6 Analysis of Algorithms
- •Exercises for Chapter 8
- •Quiz on Chapter 8
- •9.1 Recursion
- •9.1.1 Recursive Binary Search
- •9.1.2 Towers of Hanoi
- •9.1.3 A Recursive Sorting Algorithm
- •9.1.4 Blob Counting
- •9.2 Linked Data Structures
- •9.2.1 Recursive Linking
- •9.2.2 Linked Lists
- •9.2.3 Basic Linked List Processing
- •9.2.4 Inserting into a Linked List
- •9.2.5 Deleting from a Linked List
- •9.3 Stacks, Queues, and ADTs
- •9.3.1 Stacks
- •9.3.2 Queues
- •9.4 Binary Trees
- •9.4.1 Tree Traversal
- •9.4.2 Binary Sort Trees
- •9.4.3 Expression Trees
- •9.5 A Simple Recursive Descent Parser
- •9.5.1 Backus-Naur Form
- •9.5.2 Recursive Descent Parsing
- •9.5.3 Building an Expression Tree
- •Exercises for Chapter 9
- •Quiz on Chapter 9
- •10.1 Generic Programming
- •10.1.1 Generic Programming in Smalltalk
- •10.1.2 Generic Programming in C++
- •10.1.3 Generic Programming in Java
- •10.1.4 The Java Collection Framework
- •10.1.6 Equality and Comparison
- •10.1.7 Generics and Wrapper Classes
- •10.2 Lists and Sets
- •10.2.1 ArrayList and LinkedList
- •10.2.2 Sorting
- •10.2.3 TreeSet and HashSet
- •10.2.4 EnumSet
- •10.3 Maps
- •10.3.1 The Map Interface
- •10.3.2 Views, SubSets, and SubMaps
- •10.3.3 Hash Tables and Hash Codes
- •10.4 Programming with the Collection Framework
- •10.4.1 Symbol Tables
- •10.4.2 Sets Inside a Map
- •10.4.3 Using a Comparator
- •10.4.4 Word Counting
- •10.5 Writing Generic Classes and Methods
- •10.5.1 Simple Generic Classes
- •10.5.2 Simple Generic Methods
- •10.5.3 Type Wildcards
- •10.5.4 Bounded Types
- •Exercises for Chapter 10
- •Quiz on Chapter 10
- •11 Files and Networking
- •11.1 Streams, Readers, and Writers
- •11.1.1 Character and Byte Streams
- •11.1.2 PrintWriter
- •11.1.3 Data Streams
- •11.1.4 Reading Text
- •11.1.5 The Scanner Class
- •11.1.6 Serialized Object I/O
- •11.2 Files
- •11.2.1 Reading and Writing Files
- •11.2.2 Files and Directories
- •11.2.3 File Dialog Boxes
- •11.3 Programming With Files
- •11.3.1 Copying a File
- •11.3.2 Persistent Data
- •11.3.3 Files in GUI Programs
- •11.3.4 Storing Objects in Files
- •11.4 Networking
- •11.4.1 URLs and URLConnections
- •11.4.2 TCP/IP and Client/Server
- •11.4.3 Sockets
- •11.4.4 A Trivial Client/Server
- •11.4.5 A Simple Network Chat
- •11.5 Network Programming and Threads
- •11.5.1 A Threaded GUI Chat Program.
- •11.5.2 A Multithreaded Server
- •11.5.3 Distributed Computing
- •11.6 A Brief Introduction to XML
- •11.6.1 Basic XML Syntax
- •11.6.2 XMLEncoder and XMLDecoder
- •11.6.3 Working With the DOM
- •Exercises for Chapter 11
- •Quiz on Chapter 11
- •12 Advanced GUI Programming
- •12.1 Images and Resources
- •12.1.2 Working With Pixels
- •12.1.3 Resources
- •12.1.4 Cursors and Icons
- •12.1.5 Image File I/O
- •12.2 Fancier Graphics
- •12.2.1 Measuring Text
- •12.2.2 Transparency
- •12.2.3 Antialiasing
- •12.2.4 Strokes and Paints
- •12.2.5 Transforms
- •12.3 Actions and Buttons
- •12.3.1 Action and AbstractAction
- •12.3.2 Icons on Buttons
- •12.3.3 Radio Buttons
- •12.3.4 Toolbars
- •12.3.5 Keyboard Accelerators
- •12.3.6 HTML on Buttons
- •12.4 Complex Components and MVC
- •12.4.1 Model-View-Controller
- •12.4.2 Lists and ListModels
- •12.4.3 Tables and TableModels
- •12.4.4 Documents and Editors
- •12.4.5 Custom Components
- •12.5 Finishing Touches
- •12.5.1 The Mandelbrot Set
- •12.5.2 Design of the Program
- •12.5.3 Internationalization
- •12.5.4 Events, Events, Events
- •12.5.5 Custom Dialogs
- •12.5.6 Preferences
- •Exercises for Chapter 12
- •Quiz on Chapter 12
- •Appendix: Source Files
CHAPTER 8. CORRECTNESS AND ROBUSTNESS |
393 |
/* Convert the measurement to inches and add it to the total. */
if (units.equals("inch")
|| units.equals("inches") || units.equals("in")) { inches += measurement;
}
else if (units.equals("foot")
|| units.equals("feet") || units.equals("ft")) { inches += measurement * 12;
}
else if (units.equals("yard")
|| units.equals("yards") || units.equals("yd")) { inches += measurement * 36;
}
else if (units.equals("mile")
|| units.equals("miles") || units.equals("mi")) { inches += measurement * 12 * 5280;
}
else {
throw new ParseError("\"" + units
+ "\" is not a legal unit of measure.");
}
/* Look ahead to see whether the next thing on the line is the end-of-line. */
skipBlanks();
ch = TextIO.peek(); } // end while
return inches;
} // end readMeasurement()
In the main program, this subroutine is called in a try statement of the form
try {
inches = readMeasurement();
}
catch (ParseError e) {
. . . // Handle the error.
}
The complete program can be found in the file LengthConverter3.java. From the user’s point of view, this program has exactly the same behavior as the program LengthConverter2 from the previous section. Internally, however, the programs are significantly di erent, since LengthConverter3 uses exception-handling.
8.4 Assertions
In this short section, we look at assertions, another feature of the Java programming (online) language that can be used to aid in the development of correct and robust programs.
Recall that a precondition is a condition that must be true at a certain point in a program, for the execution of the program to continue correctly from that point. In the case where
CHAPTER 8. CORRECTNESS AND ROBUSTNESS |
394 |
there is a chance that the precondition might not be satisfied—for example, if it depends on input from the user—then it’s a good idea to insert an if statement to test it. But then the question arises, What should be done if the precondition does not hold? One option is to throw an exception. This will terminate the program, unless the exception is caught and handled elsewhere in the program.
In many cases, of course, instead of using an if statement to test whether a precondition holds, a programmer tries to write the program in a way that will guarantee that the precondition holds. In that case, the test should not be necessary, and the if statement can be avoided. The problem is that programmers are not perfect. In spite of the programmer’s intention, the program might contain a bug that screws up the precondition. So maybe it’s a good idea to check the precondition—at least during the debugging phase of program development.
Similarly, a postcondition is a condition that is true at a certain point in the program as a consequence of the code that has been executed before that point. Assuming that the code is correctly written, a postcondition is guaranteed to be true, but here again testing whether a desired postcondition is actually true is a way of checking for a bug that might have screwed up the postcondition. This is something that might be desirable during debugging.
The programming languages C and C++ have always had a facility for adding what are called assertions to a program. These assertions take the form “assert(hconditioni)”, where hconditioni is a boolean-valued expression. This condition expresses a precondition or postcondition that should hold at that point in the program. When the computer encounters an assertion during the execution of the program, it evaluates the condition. If the condition is false, the program is terminated. Otherwise, the program continues normally. This allows the programmer’s belief that the condition is true to be tested; if if it not true, that indicates that the part of the program that preceded the assertion contained a bug. One nice thing about assertions in C and C++ is that they can be “turned o ” at compile time. That is, if the program is compiled in one way, then the assertions are included in the compiled code. If the program is compiled in another way, the assertions are not included. During debugging, the first type of compilation is used. The release version of the program is compiled with assertions turned o . The release version will be more e cient, because the computer won’t have to evaluate all the assertions.
Although early versions of Java did not have assertions, an assertion facility similar to the one in C/C++ has been available in Java since version 1.4. As with the C/C++ version, Java assertions can be turned on during debugging and turned o during normal execution. In Java, however, assertions are turned on and o at run time rather than at compile time. An assertion in the Java source code is always included in the compiled class file. When the program is run in the normal way, these assertions are ignored; since the condition in the assertion is not evaluated in this case, there is little or no performance penalty for having the assertions in the program. When the program is being debugged, it can be run with assertions enabled, as discussed below, and then the assertions can be a great help in locating and identifying bugs.
An assertion statement in Java takes one of the following two forms:
assert hcondition i ;
or
assert hcondition i : herror-messagei ;
where hconditioni is a boolean-valued expression and herror-messagei is a string or an expression of type String. The word “assert” is a reserved word in Java, which cannot be used as an
CHAPTER 8. CORRECTNESS AND ROBUSTNESS |
395 |
identifier. An assertion statement can be used anyplace in Java where a statement is legal.
If a program is run with assertions disabled, an assertion statement is equivalent to an empty statement and has no e ect. When assertions are enabled and an assertion statement is encountered in the program, the hconditioni in the assertion is evaluated. If the value is true, the program proceeds normally. If the value of the condition is false, then an exception of type java.lang.AssertionError is thrown, and the program will crash (unless the error is caught by a try statement). If the assert statement includes an herror-messagei, then the error message string becomes the message in the AssertionError.
So, the statement “assert hcondition i : herror-message i;" is similar to
if ( hcondition i == false )
throw new AssertionError( herror-messagei );
except that the if statement is executed whenever the program is run, and the assert statement is executed only when the program is run with assertions enabled.
The question is, when to use assertions instead of exceptions? The general rule is to use assertions to test conditions that should definitely be true, if the program is written correctly. Assertions are useful for testing a program to see whether or not it is correct and for finding the errors in an incorrect program. After testing and debugging, when the program is used in the normal way, the assertions in the program will be ignored. However, if a problem turns up later, the assertions are still there in the program to be used to help locate the error. If someone writes to you to say that your program doesn’t work when he does such-and-such, you can run the program with assertions enabled, do such-and-such, and hope that the assertions in the program will help you locate the point in the program where it goes wrong.
Consider, for example, the root() method from Subsection 8.3.3 that calculates a root of a quadratic equation. If you believe that your program will always call this method with legal arguments, then it would make sense to write the method using assertions instead of exceptions:
/**
*Returns the larger of the two roots of the quadratic equation
*A*x*x + B*x + C = 0, provided it has any roots.
*Precondition: A != 0 and B*B - 4*A*C >= 0.
*/
static public double root( double A, double B, double C ) {
assert A != |
0 |
: "Leading coefficient of quadratic equation cannot be zero."; |
double disc |
= B*B - 4*A*C; |
|
assert disc |
>= 0 : "Discriminant of quadratic equation cannot be negative."; |
|
return (-B |
+ |
Math.sqrt(disc)) / (2*A); |
}
The assertions are not checked when the program is run in the normal way. If you are correct in your belief that the method is never called with illegal arguments, then checking the conditions in the assertions would be unnecessary. If your belief is not correct, the problem should turn up during testing or debugging, when the program is run with the assertions enabled.
If the root() method is part of a software library that you expect other people to use, then the situation is less clear. Sun’s Java documentation advises that assertions should not be used for checking the contract of public methods: If the caller of a method violates the contract by passing illegal parameters, then an exception should be thrown. This will enforce the contract whether or not assertions are enabled. (However, while it’s true that Java programmers expect the contract of a method to be enforced with exceptions, there are reasonable arguments for using assertions instead, in some cases.)