languages such as Java, Pascal, or C++. A program written in a ...... If I say âthe President went fishing,â I mean
Introduction to Programming Using Java Version 5.0, December 2006
David J. Eck Hobart and William Smith Colleges
ii
c
2006, David J. Eck David J. Eck (
[email protected]) Department of Mathematics and Computer Science Hobart and William Smith Colleges Geneva, NY 14456 This book can be distributed in unmodified form with no restrictions. Modified versions can be made and distributed provided they are distributed under the same license as the original. More specifically: This work is licensed under the Creative Commons Attribution-Share Alike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/bysa/2.5/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. The web site for this book is: http://math.hws.edu/javanotes
Contents Preface 1 The Mental Landscape 1.1 Machine Language . . . . . . 1.2 Asynchronous Events . . . . . 1.3 The Java Virtual Machine . . 1.4 Building Blocks of Programs 1.5 Object-oriented Programming 1.6 The Modern User Interface . 1.7 The Internet . . . . . . . . . Quiz on Chapter 1 . . . . . . . . .
xiii
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
1 1 3 6 8 9 12 14 17
2 Names and Things 2.1 The Basic Java Application . . . . . . . . . . 2.2 Variables and Types . . . . . . . . . . . . . . 2.2.1 Variables . . . . . . . . . . . . . . . . 2.2.2 Types and Literals . . . . . . . . . . . 2.2.3 Variables in Programs . . . . . . . . . 2.3 Objects and Subroutines . . . . . . . . . . . . 2.3.1 Built-in Subroutines and Functions . . 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.6 Assignment Operators and Type-Casts 2.5.7 Type Conversion of Strings . . . . . . 2.5.8 Precedence Rules . . . . . . . . . . . . 2.6 Programming Environments . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
19 19 22 23 24 27 28 29 32 34 36 37 38 39 41 43 44 45 46 46 47 48 48 50 50 51
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
iii
. . . . . . . .
. . . . . . . .
. . . . . . . .
iv
CONTENTS 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 . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
51 52 54 56 58 60
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.1 Pseudocode and Stepwise Refinement 3.2.2 The 3N+1 Problem . . . . . . . . . . 3.2.3 Coding, Testing, Debugging . . . . . . 3.3 while and do..while . . . . . . . . . . . . . . . 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.4.4 Enums and for-each 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.6.4 Definite Assignment . . . . . . . . . . 3.7 Exceptions and try..catch . . . . . . . . . . . 3.7.1 Exceptions . . . . . . . . . . . . . . . 3.7.2 try..catch . . . . . . . . . . . . . . . . 3.7.3 Exceptions in TextIO . . . . . . . . . 3.8 GUI Programming . . . . . . . . . . . . . . . Exercises for Chapter 3 . . . . . . . . . . . . . . . Quiz on Chapter 3 . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61 61 61 62 64 66 66 69 72 73 74 76 78 79 80 83 85 87 89 89 89 91 95 96 96 97 98 99 100 100 101 102 104 111 114
4 Subroutines 4.1 Black Boxes . . . . . . . . . . . . 4.2 Static Subroutines and Variables 4.2.1 Subroutine Definitions . . 4.2.2 Calling Subroutines . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
117 117 119 119 121
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
v
CONTENTS 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.2 Java’s Standard Packages . . . . 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 . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
122 124 127 127 128 129 130 132 133 134 134 135 138 140 140 141 142 144 146 146 147 151 153 154 155 158 161 164
5 Objects and Classes 5.1 Objects and Instance Methods . . . . . . . 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.1 Some Built-in Classes . . . . . . . . 5.3.2 Wrapper Classes and Autoboxing . . 5.3.3 The class “Object” . . . . . . . . . . 5.3.4 Object-oriented Analysis and Design 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 . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
165 165 166 167 172 173 173 174 179 179 180 181 182 183 185 185 187 191
vi
CONTENTS 5.5
Inheritance and Polymorphism . . . . . . . . 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.4 Mixing Static and Non-static . . . . . 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 . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
194 194 196 197 200 202 205 205 206 208 209 209 211 214 214 216 217 220 223
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
225 225 227 229 230 231 231 233 235 238 240 242 243 244 245 246 247 251 252 253 256 258 262 264 264 266 269
vii
CONTENTS 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 . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
270 273 275 276 277 278 279 280 282 283 285 287 289 291 293 296 297 300 302 304 306 311
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.2 Arrays and for-each 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 . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
313 313 314 314 316 318 318 320 321 322 324 327 329 329 332 335 339 342 343 343 345 348 349 351
viii
CONTENTS 7.5
Multi-dimensional Arrays . . . . . . . . . 7.5.1 Creating Two-dimensional Arrays 7.5.2 Using Two-dimensional Arrays . . 7.5.3 Example: Checkers . . . . . . . . . Exercises for Chapter 7 . . . . . . . . . . . . . Quiz on Chapter 7 . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
352 352 354 357 364 370
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.3 Mutual Exclusion with “synchronized” 8.5.4 Wait and Notify . . . . . . . . . . . . 8.5.5 Volatile Variables . . . . . . . . . . . . 8.6 Analysis of Algorithms . . . . . . . . . . . . . Exercises for Chapter 8 . . . . . . . . . . . . . . . Quiz on Chapter 8 . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
373 . 373 . 374 . 375 . 377 . 378 . 378 . 381 . 385 . 386 . 388 . 390 . 392 . 393 . 396 . 399 . 400 . 404 . 405 . 408 . 412 . 413 . 419 . 424
9 Linked width=160 height=160>
Call this file Checkerboard.html. This is the source code for a simple Web page that shows nothing but your applet. You can open the file in a Web browser or with Sun’s appletviewer program. The compiled class file, Checkerboard.class, must be in the same directory with the Web-page file, Checkerboard.html. (If you are using the Eclipse Integrated Development Environment, you can simply right-click the name of the source code file in the Package Explorer. In the pop-up menu, go to “Run As” then to “Java Applet”. This will open the window in which the applet appears. The default size for the window is bigger than 160-by-160, so the drawing of the checkerboard will not fill the entire window.) 7. Write an animation applet that shows a checkerboard pattern in which the even numbered rows slide to the left while the odd numbered rows slide to the right. You can assume that the applet is 160 by 160 pixels. Each row should be offset from its usual position by the amount getFrameNumber() % 40. Hints: Anything you draw outside the boundaries of the applet will be invisible, so you can draw more than 8 squares in a row. You can use negative values of x in g.fillRect(x,y,w,h). (Before trying to do this exercise, it would be a good idea to look at a working applet, which can be found in the on-line version of this book.) Your applet will extend the non-standard class, SimpleAnimationApplet2, which was introduced in Section 3.8. The compiled class files, SimpleAnimationApplet2.class and SimpleAnimationApplet2$1.class, must be in the same directory as your Web-page source file along with the compiled class file for your own class. These files are produced when you compile SimpleAnimationApplet2.java. Assuming that the name of your class is SlidingCheckerboard, then the source file for the Web page should contain the lines:
114
CHAPTER 3. CONTROL
Quiz on Chapter 3 1. What is an algorithm? 2. Explain briefly what is meant by “pseudocode” and how is it useful in the development of algorithms. 3. What is a block statement? How are block statements used in Java programs. 4. What is the main difference between a while loop and a do..while loop? 5. What does it mean to prime a loop? 6. Explain what is meant by an animation and how a computer displays an animation. 7. Write a for loop that will print out all the multiples of 3 from 3 to 36, that is: 3 6 9 12 15 18 21 24 27 30 33 36. 8. Fill in the following main() routine so that it will ask the user to enter an integer, read the user’s response, and tell the user whether the number entered is even or odd. (You can use TextIO.getInt() to read the integer. Recall that an integer n is even if n % 2 == 0.) public static void main(String[] args) { // Fill in the body of this subroutine! }
9. Suppose that s1 and s2 are variables of type String, whose values are expected to be string representations of values of type int. Write a code segment that will compute and print the integer sum of those values, or will print an error message if the values cannot successfully be converted into integers. (Use a try..catch statement.) 10. Show the exact output that would be produced by the following main() routine: public static void main(String[] args) { int N; N = 1; while (N 0) { x = x - 1; y = y * x; System.out.println(y); } }
115
Quiz 12. What output is produced by the following program segment? name.charAt(i) is the i-th character in the string, name.) String name; int i; boolean startWord; name = "Richard M. Nixon"; startWord = true; for (i = 0; i < name.length(); i++) { if (startWord) System.out.println(name.charAt(i)); if (name.charAt(i) == ’ ’) startWord = true; else startWord = false; }
Why?
(Recall that
116
CHAPTER 3. CONTROL
Chapter 4
Programming in the Large I: Subroutines One way to break up a complex program into manageable pieces is to use subroutines. A subroutine consists of the instructions for carrying out a certain task, grouped together and given a name. Elsewhere in the program, that name can be used as a stand-in for the whole set of instructions. As a computer executes a program, whenever it encounters a subroutine name, it executes all the instructions necessary to carry out the task associated with that subroutine. Subroutines can be used over and over, at different places in the program. A subroutine can even be used inside another subroutine. This allows you to write simple subroutines and then use them to help write more complex subroutines, which can then be used in turn in other subroutines. In this way, very complex programs can be built up step-by-step, where each step in the construction is reasonably simple. As mentioned in Section 3.8, subroutines in Java can be either static or non-static. This chapter covers static subroutines only. Non-static subroutines, which are used in true objectoriented programming, will be covered in the next chapter.
4.1
Black Boxes
A subroutine consists of instructions for performing some task, chunked together and given a name. “Chunking” allows you to deal with a potentially very complicated task as a single concept. Instead of worrying about the many, many steps that the computer might have to go though to perform that task, you just need to remember the name of the subroutine. Whenever you want your program to perform the task, you just call the subroutine. Subroutines are a major tool for dealing with complexity. A subroutine is sometimes said to be a “black box” because you can’t see what’s “inside” it (or, to be more precise, you usually don’t want to see inside it, because then you would have to deal with all the complexity that the subroutine is meant to hide). Of course, a black box that has no way of interacting with the rest of the world would be pretty useless. A black box needs some kind of interface with the rest of the world, which allows some interaction between what’s inside the box and what’s outside. A physical black box might have buttons on the outside that you can push, dials that you can set, and slots that can be used for passing information back and forth. Since we are trying to hide complexity, not create it, we have the first rule of black boxes: 117
118
CHAPTER 4. SUBROUTINES The interface of a black box should be fairly straightforward, well-defined, and easy to understand.
Are there any examples of black boxes in the real world? Yes; in fact, you are surrounded by them. Your television, your car, your VCR, your refrigerator. . . . You can turn your television on and off, change channels, and set the volume by using elements of the television’s interface— dials, remote control, don’t forget to plug in the power—without understanding anything about how the thing actually works. The same goes for a VCR, although if stories about how hard people find it to set the time on a VCR are true, maybe the VCR violates the simple interface rule. Now, a black box does have an inside—the code in a subroutine that actually performs the task, all the electronics inside your television set. The inside of a black box is called its implementation. The second rule of black boxes is that: To use a black box, you shouldn’t need to know anything about its implementation; all you need to know is its interface. In fact, it should be possible to change the implementation, as long as the behavior of the box, as seen from the outside, remains unchanged. For example, when the insides of TV sets went from using vacuum tubes to using transistors, the users of the sets didn’t even need to know about it—or even know what it means. Similarly, it should be possible to rewrite the inside of a subroutine, to use more efficient code, for example, without affecting the programs that use that subroutine. Of course, to have a black box, someone must have designed and built the implementation in the first place. The black box idea works to the advantage of the implementor as well as of the user of the black box. After all, the black box might be used in an unlimited number of different situations. The implementor of the black box doesn’t need to know about any of that. The implementor just needs to make sure that the box performs its assigned task and interfaces correctly with the rest of the world. This is the third rule of black boxes: The implementor of a black box should not need to know anything about the larger systems in which the box will be used. In a way, a black box divides the world into two parts: the inside (implementation) and the outside. The interface is at the boundary, connecting those two parts.
∗ ∗ ∗ By the way, you should not think of an interface as just the physical connection between the box and the rest of the world. The interface also includes a specification of what the box does and how it can be controlled by using the elements of the physical interface. It’s not enough to say that a TV set has a power switch; you need to specify that the power switch is used to turn the TV on and off! To put this in computer science terms, the interface of a subroutine has a semantic as well as a syntactic component. The syntactic part of the interface tells you just what you have to type in order to call the subroutine. The semantic component specifies exactly what task the subroutine will accomplish. To write a legal program, you need to know the syntactic specification of the subroutine. To understand the purpose of the subroutine and to use it effectively, you need to know the subroutine’s semantic specification. I will refer to both parts of the interface—syntactic and semantic—collectively as the contract of the subroutine.
119
4.2. STATIC SUBROUTINES AND VARIABLES
The contract of a subroutine says, essentially, “Here is what you have to do to use me, and here is what I will do for you, guaranteed.” When you write a subroutine, the comments that you write for the subroutine should make the contract very clear. (I should admit that in practice, subroutines’ contracts are often inadequately specified, much to the regret and annoyance of the programmers who have to use them.) For the rest of this chapter, I turn from general ideas about black boxes and subroutines in general to the specifics of writing and using subroutines in Java. But keep the general ideas and principles in mind. They are the reasons that subroutines exist in the first place, and they are your guidelines for using them. This should be especially clear in Section 4.6, where I will discuss subroutines as a tool in program development.
∗ ∗ ∗ You should keep in mind that subroutines are not the only example of black boxes in programming. For example, a class is also a black box. We’ll see that a class can have a “public” part, representing its interface, and a “private” part that is entirely inside its hidden implementation. All the principles of black boxes apply to classes as well as to subroutines.
4.2
Static Subroutines and Static Variables
Every
subroutine in Java must be defined inside some class. This makes Java rather unusual among programming languages, since most languages allow free-floating, independent subroutines. One purpose of a class is to group together related subroutines and variables. Perhaps the designers of Java felt that everything must be related to something. As a less philosophical motivation, Java’s designers wanted to place firm controls on the ways things are named, since a Java program potentially has access to a huge number of subroutines created by many different programmers. The fact that those subroutines are grouped into named classes (and classes are grouped into named “packages”) helps control the confusion that might result from so many different names. A subroutine that is a member of a class is often called a method , and “method” is the term that most people prefer for subroutines in Java. I will start using the term “method” occasionally; however, I will continue to prefer the more general term “subroutine” for static subroutines. I will use the term “method” most often to refer to non-static subroutines, which belong to objects rather than to classes. This chapter will deal with static subroutines almost exclusively. We’ll turn to non-static methods and object-oriented programming in the next chapter.
4.2.1
Subroutine Definitions
A subroutine definition in Java takes the form: hmodifier i hreturn-type i hstatements i }
hsubroutine-name i
( hparameter-list i ) {
It will take us a while—most of the chapter—to get through what all this means in detail. Of course, you’ve already seen examples of subroutines in previous chapters, such as the main() routine of a program and the paint() routine of an applet. So you are familiar with the general format. The hstatementsi between the braces, { and }, in a subroutine definition make up the body of the subroutine. These statements are the inside, or implementation part, of the “black box”,
120
CHAPTER 4. SUBROUTINES
as discussed in the previous section. They are the instructions that the computer executes when the method is called. Subroutines can contain any of the statements discussed in Chapter 2 and Chapter 3. The hmodifiersi that can occur at the beginning of a subroutine definition are words that set certain characteristics of the subroutine, such as whether it is static or not. The modifiers that you’ve seen so far are “static” and “public”. There are only about a half-dozen possible modifiers altogether. If the subroutine is a function, whose job is to compute some value, then the hreturn-typei is used to specify the type of value that is returned by the function. We’ll be looking at functions and return types in some detail in Section 4.4. If the subroutine is not a function, then the hreturn-typei is replaced by the special value void, which indicates that no value is returned. The term “void” is meant to indicate that the return value is empty or non-existent. Finally, we come to the hparameter-listi of the method. Parameters are part of the interface of a subroutine. They represent information that is passed into the subroutine from outside, to be used by the subroutine’s internal computations. For a concrete example, imagine a class named Television that includes a method named changeChannel(). The immediate question is: What channel should it change to? A parameter can be used to answer this question. Since the channel number is an integer, the type of the parameter would be int, and the declaration of the changeChannel() method might look like public void changeChannel(int channelNum) { ... }
This declaration specifies that changeChannel() has a parameter named channelNum of type int. However, channelNum does not yet have any particular value. A value for channelNum is provided when the subroutine is called; for example: changeChannel(17); The parameter list in a subroutine can be empty, or it can consist of one or more parameter declarations of the form htypei hparameter-namei. If there are several declarations, they are separated by commas. Note that each declaration can name only one parameter. For example, if you want two parameters of type double, you have to say “double x, double y”, rather than “double x, y”. Parameters are covered in more detail in the next section. Here are a few examples of subroutine definitions, leaving out the statements that define what the subroutines do: public static void playGame() { // "public" and "static" are modifiers; "void" is the // return-type; "playGame" is the subroutine-name; // the parameter-list is empty. . . . // Statements that define what playGame does go here. } int getNextN(int N) { // There are no modifiers; "int" in the return-type // "getNextN" is the subroutine-name; the parameter-list // includes one parameter whose name is "N" and whose // type is "int". . . . // Statements that define what playGame does go here. } static boolean lessThan(double x, double y) { // "static" is a modifier; "boolean" is the // return-type; "lessThan" is the subroutine-name; the
4.2. STATIC SUBROUTINES AND VARIABLES
121
// parameter-list includes two parameters whose names are // "x" and "y", and the type of each of these parameters // is "double". . . . // Statements that define what playGame does go here. }
In the second example given here, getNextN is a non-static method, since its definition does not include the modifier “static”—and so it’s not an example that we should be looking at in this chapter! The other modifier shown in the examples is “public”. This modifier indicates that the method can be called from anywhere in a program, even from outside the class where the method is defined. There is another modifier, “private”, which indicates that the method can be called only from inside the same class. The modifiers public and private are called access specifiers. If no access specifier is given for a method, then by default, that method can be called from anywhere in the “package” that contains the class, but not from outside that package. (Packages were introduced in Subsection 2.6.4, and you’ll learn more about them later in this chapter, in Section 4.5.) There is one other access modifier, protected, which will only become relevant when we turn to object-oriented programming in Chapter 5. Note, by the way, that the main() routine of a program follows the usual syntax rules for a subroutine. In public static void main(String[] args) { ... }
the modifiers are public and static, the return type is void, the subroutine name is main, and the parameter list is “String[] args”. The only question might be about “String[]”, which has to be a type if it is to match the syntax of a parameter list. In fact, String[] represents a so-called “array type”, so the syntax is valid. We will cover arrays in Chapter 7. (The parameter, args, represents information provided to the program when the main() routine is called by the system. In case you know the term, the information consists of any “command-line arguments” specified in the command that the user typed to run the program.) You’ve already had some experience with filling in the implementation of a subroutine. In this chapter, you’ll learn all about writing your own complete subroutine definitions, including the interface part.
4.2.2
Calling Subroutines
When you define a subroutine, all you are doing is telling the computer that the subroutine exists and what it does. The subroutine doesn’t actually get executed until it is called. (This is true even for the main() routine in a class—even though you don’t call it, it is called by the system when the system runs your program.) For example, the playGame() method given as an example above could be called using the following subroutine call statement: playGame();
This statement could occur anywhere in the same class that includes the definition of playGame(), whether in a main() method or in some other subroutine. Since playGame() is a public method, it can also be called from other classes, but in that case, you have to tell the computer which class it comes from. Since playGame() is a static method, its full name includes the name of the class in which it is defined. Let’s say, for example, that playGame() is defined in a class named Poker. Then to call playGame() from outside the Poker class, you would have to say Poker.playGame();
122
CHAPTER 4. SUBROUTINES
The use of the class name here tells the computer which class to look in to find the method. It also lets you distinguish between Poker.playGame() and other potential playGame() methods defined in other classes, such as Roulette.playGame() or Blackjack.playGame(). More generally, a subroutine call statement for a static subroutine takes the form hsubroutine-name i(hparameters i);
if the subroutine that is being called is in the same class, or hclass-name i.hsubroutine-name i(hparameters i);
if the subroutine is defined elsewhere, in a different class. (Non-static methods belong to objects rather than classes, and they are called using object names instead of class names. More on that later.) Note that the parameter list can be empty, as in the playGame() example, but the parentheses must be there even if there is nothing between them.
4.2.3
Subroutines in Programs
It’s time to give an example of what a complete program looks like, when it includes other subroutines in addition to the main() routine. Let’s write a program that plays a guessing game with the user. The computer will choose a random number between 1 and 100, and the user will try to guess it. The computer tells the user whether the guess is high or low or correct. If the user gets the number after six guesses or fewer, the user wins the game. After each game, the user has the option of continuing with another game. Since playing one game can be thought of as a single, coherent task, it makes sense to write a subroutine that will play one guessing game with the user. The main() routine will use a loop to call the playGame() subroutine over and over, as many times as the user wants to play. We approach the problem of designing the playGame() subroutine the same way we write a main() routine: Start with an outline of the algorithm and apply stepwise refinement. Here is a short pseudocode algorithm for a guessing game program: Pick a random number while the game is not over: Get the user’s guess Tell the user whether the guess is high, low, or correct.
The test for whether the game is over is complicated, since the game ends if either the user makes a correct guess or the number of guesses is six. As in many cases, the easiest thing to do is to use a “while (true)” loop and use break to end the loop whenever we find a reason to do so. Also, if we are going to end the game after six guesses, we’ll have to keep track of the number of guesses that the user has made. Filling out the algorithm gives: Let computersNumber be a random number between 1 and 100 Let guessCount = 0 while (true): Get the user’s guess Count the guess by adding 1 to guess count if the user’s guess equals computersNumber: Tell the user he won break out of the loop if the number of guesses is 6: Tell the user he lost break out of the loop if the user’s guess is less than computersNumber:
4.2. STATIC SUBROUTINES AND VARIABLES
123
Tell the user the guess was low else if the user’s guess is higher than computersNumber: Tell the user the guess was high
With variable declarations added and translated into Java, this becomes the definition of the playGame() routine. A random integer between 1 and 100 can be computed as (int)(100 * Math.random()) + 1. I’ve cleaned up the interaction with the user to make it flow better. static void playGame() { int computersNumber; // A random number picked by the computer. int usersGuess; // A number entered by user as a guess. int guessCount; // Number of guesses the user has made. computersNumber = (int)(100 * Math.random()) + 1; // The value assigned to computersNumber is a randomly // chosen integer between 1 and 100, inclusive. guessCount = 0; TextIO.putln(); TextIO.put("What is your first guess? "); while (true) { usersGuess = TextIO.getInt(); // Get the user’s guess. guessCount++; if (usersGuess == computersNumber) { TextIO.putln("You got it in " + guessCount + " guesses! My number was " + computersNumber); break; // The game is over; the user has won. } if (guessCount == 6) { TextIO.putln("You didn’t get the number in 6 guesses."); TextIO.putln("You lose. My number was " + computersNumber); break; // The game is over; the user has lost. } // If we get to this point, the game continues. // Tell the user if the guess was too high or too low. if (usersGuess < computersNumber) TextIO.put("That’s too low. Try again: "); else if (usersGuess > computersNumber) TextIO.put("That’s too high. Try again: "); } TextIO.putln(); } // end of playGame()
Now, where exactly should you put this? It should be part of the same class as the main() routine, but not inside the main routine. It is not legal to have one subroutine physically nested inside another. The main() routine will call playGame(), but not contain it physically. You can put the definition of playGame() either before or after the main() routine. Java is not very picky about having the members of a class in any particular order. It’s pretty easy to write the main routine. You’ve done things like this before. Here’s what the complete program looks like (except that a serious program needs more comments than I’ve included here). public class GuessingGame { public static void main(String[] args) { TextIO.putln("Let’s play a game. I’ll pick a number between"); TextIO.putln("1 and 100, and you try to guess it.");
124
CHAPTER 4. SUBROUTINES boolean playAgain; do { playGame(); // call subroutine to play one game TextIO.put("Would you like to play again? "); playAgain = TextIO.getlnBoolean(); } while (playAgain); TextIO.putln("Thanks for playing. Goodbye."); } // end of main() static void playGame() { int computersNumber; // A random number picked by the computer. int usersGuess; // A number entered by user as a guess. int guessCount; // Number of guesses the user has made. computersNumber = (int)(100 * Math.random()) + 1; // The value assigned to computersNumber is a randomly // chosen integer between 1 and 100, inclusive. guessCount = 0; TextIO.putln(); TextIO.put("What is your first guess? "); while (true) { usersGuess = TextIO.getInt(); // Get the user’s guess. guessCount++; if (usersGuess == computersNumber) { TextIO.putln("You got it in " + guessCount + " guesses! My number was " + computersNumber); break; // The game is over; the user has won. } if (guessCount == 6) { TextIO.putln("You didn’t get the number in 6 guesses."); TextIO.putln("You lose. My number was " + computersNumber); break; // The game is over; the user has lost. } // If we get to this point, the game continues. // Tell the user if the guess was too high or too low. if (usersGuess < computersNumber) TextIO.put("That’s too low. Try again: "); else if (usersGuess > computersNumber) TextIO.put("That’s too high. Try again: "); } TextIO.putln(); } // end of playGame() } // end of class GuessingGame
Take some time to read the program carefully and figure out how it works. And try to convince yourself that even in this relatively simple case, breaking up the program into two methods makes the program easier to understand and probably made it easier to write each piece.
4.2.4
Member Variables
A class can include other things besides subroutines. In particular, it can also include variable declarations. Of course, you can declare variables inside subroutines. Those are called local variables. However, you can also have variables that are not part of any subroutine. To
4.2. STATIC SUBROUTINES AND VARIABLES
125
distinguish such variables from local variables, we call them member variables, since they are members of a class. Just as with subroutines, member variables can be either static or non-static. In this chapter, we’ll stick to static variables. A static member variable belongs to the class itself, and it exists as long as the class exists. Memory is allocated for the variable when the class is first loaded by the Java interpreter. Any assignment statement that assigns a value to the variable changes the content of that memory, no matter where that assignment statement is located in the program. Any time the variable is used in an expression, the value is fetched from that same memory, no matter where the expression is located in the program. This means that the value of a static member variable can be set in one subroutine and used in another subroutine. Static member variables are “shared” by all the static subroutines in the class. A local variable in a subroutine, on the other hand, exists only while that subroutine is being executed, and is completely inaccessible from outside that one subroutine. The declaration of a member variable looks just like the declaration of a local variable except for two things: The member variable is declared outside any subroutine (although it still has to be inside a class), and the declaration can be marked with modifiers such as static, public, and private. Since we are only working with static member variables for now, every declaration of a member variable in this chapter will include the modifier static. They might also be marked as public or private. For example: static String usersName; public static int numberOfPlayers; private static double velocity, time;
A static member variable that is not declared to be private can be accessed from outside the class where it is defined, as well as inside. When it is used in some other class, it must be referred to with a compound identifier of the form hclass-namei.hvariable-namei. For example, the System class contains the public static member variable named out, and you use this variable in your own classes by referring to System.out. If numberOfPlayers is a public static member variable in a class named Poker, then subroutines in the Poker class would refer to it simply as numberOfPlayers, while subroutines in another class would refer to it as Poker.numberOfPlayers. As an example, let’s add a static member variable to the GuessingGame class that we wrote earlier in this section. This variable will be used to keep track of how many games the user wins. We’ll call the variable gamesWon and declare it with the statement “static int gamesWon;” In the playGame() routine, we add 1 to gamesWon if the user wins the game. At the end of the main() routine, we print out the value of gamesWon. It would be impossible to do the same thing with a local variable, since we need access to the same variable from both subroutines. When you declare a local variable in a subroutine, you have to assign a value to that variable before you can do anything with it. Member variables, on the other hand are automatically initialized with a default value. For numeric variables, the default value is zero. For boolean variables, the default is false. And for char variables, it’s the unprintable character that has Unicode code number zero. (For objects, such as Strings, the default initial value is a special value called null, which we won’t encounter officially until later.) Since it is of type int, the static member variable gamesWon automatically gets assigned an initial value of zero. This happens to be the correct initial value for a variable that is being used as a counter. You can, of course, assign a different value to the variable at the beginning of the main() routine if you are not satisfied with the default initial value.
126
CHAPTER 4. SUBROUTINES
Here’s a revised version of GuessingGame.java that includes the gamesWon variable. The changes from the above version are shown in italic: public class GuessingGame2 { static int gamesWon;
// The number of games won by // the user.
public static void main(String[] args) { gamesWon = 0; // This is actually redundant, since 0 is // the default initial value. TextIO.putln("Let’s play a game. I’ll pick a number between"); TextIO.putln("1 and 100, and you try to guess it."); boolean playAgain; do { playGame(); // call subroutine to play one game TextIO.put("Would you like to play again? "); playAgain = TextIO.getlnBoolean(); } while (playAgain); TextIO.putln(); TextIO.putln("You won " + gamesWon + " games."); TextIO.putln("Thanks for playing. Goodbye."); } // end of main() static void playGame() { int computersNumber; // A random number picked by the computer. int usersGuess; // A number entered by user as a guess. int guessCount; // Number of guesses the user has made. computersNumber = (int)(100 * Math.random()) + 1; // The value assigned to computersNumber is a randomly // chosen integer between 1 and 100, inclusive. guessCount = 0; TextIO.putln(); TextIO.put("What is your first guess? "); while (true) { usersGuess = TextIO.getInt(); // Get the user’s guess. guessCount++; if (usersGuess == computersNumber) { TextIO.putln("You got it in " + guessCount + " guesses! My number was " + computersNumber); gamesWon++; // Count this game by incrementing gamesWon. break; // The game is over; the user has won. } if (guessCount == 6) { TextIO.putln("You didn’t get the number in 6 guesses."); TextIO.putln("You lose. My number was " + computersNumber); break; // The game is over; the user has lost. } // If we get to this point, the game continues. // Tell the user if the guess was too high or too low. if (usersGuess < computersNumber) TextIO.put("That’s too low. Try again: "); else if (usersGuess > computersNumber) TextIO.put("That’s too high. Try again: "); }
127
4.3. PARAMETERS TextIO.putln(); } // end of playGame() } // end of class GuessingGame2
4.3
Parameters
If a subroutine is a black box, then a parameter provides a mechanism for passing information from the outside world into the box. Parameters are part of the interface of a subroutine. They allow you to customize the behavior of a subroutine to adapt it to a particular situation. As an analogy, consider a thermostat—a black box whose task it is to keep your house at a certain temperature. The thermostat has a parameter, namely the dial that is used to set the desired temperature. The thermostat always performs the same task: maintaining a constant temperature. However, the exact task that it performs—that is, which temperature it maintains—is customized by the setting on its dial.
4.3.1
Using Parameters
As an example, let’s go back to the “3N+1” problem that was discussed in Subsection 3.2.2. (Recall that a 3N+1 sequence is computed according to the rule, “if N is odd, multiply by 3 and add 1; if N is even, divide by 2; continue until N is equal to 1.” For example, starting from N=3 we get the sequence: 3, 10, 5, 16, 8, 4, 2, 1.) Suppose that we want to write a subroutine to print out such sequences. The subroutine will always perform the same task: Print out a 3N+1 sequence. But the exact sequence it prints out depends on the starting value of N. So, the starting value of N would be a parameter to the subroutine. The subroutine could be written like this: /** * This subroutine prints a 3N+1 sequence to standard output, using * startingValue as the initial value of N. It also prints the number * of terms in the sequence. The value of the parameter, startingValue, * must be a positive integer. */ static void print3NSequence(int startingValue) { int N; int count;
// One of the terms in the sequence. // The number of terms.
N = startingValue; // The first term is whatever value // is passed to the subroutine as // a parameter. int count = 1; // We have one term, the starting value, so far. System.out.println("The 3N+1 sequence starting from " + N); System.out.println(); System.out.println(N); // print initial term of sequence while (N > 1) { if (N % 2 == 1) N = 3 * N + 1; else N = N / 2;
// is N odd?
128
CHAPTER 4. SUBROUTINES count++; // count this term System.out.println(N); // print this term } System.out.println(); System.out.println("There were " + count + " terms in the sequence."); }
// end print3NSequence
The parameter list of this subroutine, “(int startingValue)”, specifies that the subroutine has one parameter, of type int. Within the body of the subroutine, the parameter name can be used in the same way as a variable name. However, the parameter gets its initial value from outside the subroutine. When the subroutine is called, a value must be provided for this parameter in the subroutine call statement. This value will be assigned to the parameter, startingValue, before the body of the subroutine is executed. For example, the subroutine could be called using the subroutine call statement “print3NSequence(17);”. When the computer executes this statement, the computer assigns the value 17 to startingValue and then executes the statements in the subroutine. This prints the 3N+1 sequence starting from 17. If K is a variable of type int, then when the computer executes the subroutine call statement “print3NSequence(K);”, it will take the value of the variable K, assign that value to startingValue, and execute the body of the subroutine. The class that contains print3NSequence can contain a main() routine (or other subroutines) that call print3NSequence. For example, here is a main() program that prints out 3N+1 sequences for various starting values specified by the user: public static void main(String[] args) { TextIO.putln("This program will print out 3N+1 sequences"); TextIO.putln("for starting values that you specify."); TextIO.putln(); int K; // Input from user; loop ends when K < 0. do { TextIO.putln("Enter a starting value;") TextIO.put("To end the program, enter 0: "); K = TextIO.getInt(); // Get starting value from user. if (K > 0) // Print sequence, but only if K is > 0. print3NSequence(K); } while (K > 0); // Continue only if K > 0. } // end main
Remember that before you can use this program, the definitions of main and of print3NSequence must both be wrapped inside a class definition.
4.3.2
Formal and Actual Parameters
Note that the term “parameter” is used to refer to two different, but related, concepts. There are parameters that are used in the definitions of subroutines, such as startingValue in the above example. And there are parameters that are used in subroutine call statements, such as the K in the statement “print3NSequence(K);”. Parameters in a subroutine definition are called formal parameters or dummy parameters. The parameters that are passed to a subroutine when it is called are called actual parameters or arguments. When a subroutine is called, the actual parameters in the subroutine call statement are evaluated and the values are assigned to the formal parameters in the subroutine’s definition. Then the body of the subroutine is executed.
4.3. PARAMETERS
129
A formal parameter must be a name, that is, a simple identifier.. A formal parameter is very much like a variable, and—like a variable—it has a specified type such as int, boolean, or String. An actual parameter is a value, and so it can be specified by any expression, provided that the expression computes a value of the correct type. The type of the actual parameter must be one that could legally be assigned to the formal parameter with an assignment statement. For example, if the formal parameter is of type double, then it would be legal to pass an int as the actual parameter since ints can legally be assigned to doubles. When you call a subroutine, you must provide one actual parameter for each formal parameter in the subroutine’s definition. Consider, for example, a subroutine static void doTask(int N, double x, boolean test) { // statements to perform the task go here }
This subroutine might be called with the statement doTask(17, Math.sqrt(z+1), z >= 10);
When the computer executes this statement, it has essentially the same effect as the block of statements: { int N; // Allocate memory locations for the formal parameters. double x; boolean test; N = 17; // Assign 17 to the first formal parameter, N. x = Math.sqrt(z+1); // Compute Math.sqrt(z+1), and assign it to // the second formal parameter, x. test = (z >= 10); // Evaluate "z >= 10" and assign the resulting // true/false value to the third formal // parameter, test. // statements to perform the task go here }
(There are a few technical differences between this and “doTask(17,Math.sqrt(z+1),z>=10);” —besides the amount of typing—because of questions about scope of variables and what happens when several variables or parameters have the same name.) Beginning programming students often find parameters to be surprisingly confusing. Calling a subroutine that already exists is not a problem—the idea of providing information to the subroutine in a parameter is clear enough. Writing the subroutine definition is another matter. A common mistake is to assign values to the formal parameters at the beginning of the subroutine, or to ask the user to input their values. This represents a fundamental misunderstanding. When the statements in the subroutine are executed, the formal parameters will already have values. The values come from the subroutine call statement. Remember that a subroutine is not independent. It is called by some other routine, and it is the calling routine’s responsibility to provide appropriate values for the parameters.
4.3.3
Overloading
In order to call a subroutine legally, you need to know its name, you need to know how many formal parameters it has, and you need to know the type of each parameter. This information is called the subroutine’s signature. The signature of the subroutine doTask, used as an example above, can be expressed as as: doTask(int,double,boolean). Note that the signature does
130
CHAPTER 4. SUBROUTINES
not include the names of the parameters; in fact, if you just want to use the subroutine, you don’t even need to know what the formal parameter names are, so the names are not part of the interface. Java is somewhat unusual in that it allows two different subroutines in the same class to have the same name, provided that their signatures are different. (The language C++ on which Java is based also has this feature.) When this happens, we say that the name of the subroutine is overloaded because it has several different meanings. The computer doesn’t get the subroutines mixed up. It can tell which one you want to call by the number and types of the actual parameters that you provide in the subroutine call statement. You have already seen overloading used in the TextIO class. This class includes many different methods named putln, for example. These methods all have different signatures, such as: putln(int) putln(String) putln(boolean)
putln(double) putln(char) putln()
The computer knows which of these subroutines you want to use based on the type of the actual parameter that you provide. TextIO.putln(17) calls the subroutine with signature putln(int), while TextIO.putln("Hello") calls the subroutine with signature putln(String). Of course all these different subroutines are semantically related, which is why it is acceptable programming style to use the same name for them all. But as far as the computer is concerned, printing out an int is very different from printing out a String, which is different from printing out a boolean, and so forth—so that each of these operations requires a different method. Note, by the way, that the signature does not include the subroutine’s return type. It is illegal to have two subroutines in the same class that have the same signature but that have different return types. For example, it would be a syntax error for a class to contain two methods defined as: int getln() { ... } double getln() { ... }
So it should be no surprise that in the TextIO class, the methods for reading different types are not all named getln(). In a given class, there can only be one routine that has the name getln and has no parameters. So, the input routines in TextIO are distinguished by having different names, such as getlnInt() and getlnDouble(). Java 5.0 introduced another complication: It is possible to have a single subroutine that takes a variable number of actual parameters. You have already used subroutines that do this—the formatted output routines System.out.printf and TextIO.putf. When you call these subroutines, the number of parameters in the subroutine call can be arbitrarily large, so it would be impossible to have different subroutines to handle each case. Unfortunately, writing the definition of such a subroutine requires some knowledge of arrays, which will not be covered until Chapter 7. When we get to that chapter, you’ll learn how to write subroutines with a variable number of parameters. For now, we will ignore this complication.
4.3.4
Subroutine Examples
Let’s do a few examples of writing small subroutines to perform assigned tasks. Of course, this is only one side of programming with subroutines. The task performed by a subroutine is always a subtask in a larger program. The art of designing those programs—of deciding how to
131
4.3. PARAMETERS
break them up into subtasks—is the other side of programming with subroutines. We’ll return to the question of program design in Section 4.6. As a first example, let’s write a subroutine to compute and print out all the divisors of a given positive integer. The integer will be a parameter to the subroutine. Remember that the syntax of any subroutine is: hmodifiers i hreturn-type i hstatements i }
hsubroutine-name i
( hparameter-list i ) {
Writing a subroutine always means filling out this format. The statement of the problem tells us that there is one parameter, of type int, and it tells us what the statements in the body of the subroutine should do. Since we are only working with static subroutines for now, we’ll need to use static as a modifier. We could add an access modifier (public or private), but in the absence of any instructions, I’ll leave it out. Since we are not told to return a value, the return type is void. Since no names are specified, we’ll have to make up names for the formal parameter and for the subroutine itself. I’ll use N for the parameter and printDivisors for the subroutine name. The subroutine will look like static void printDivisors( int N ) { hstatements i }
and all we have left to do is to write the statements that make up the body of the routine. This is not difficult. Just remember that you have to write the body assuming that N already has a value! The algorithm is: “For each possible divisor D in the range from 1 to N, if D evenly divides N, then print D.” Written in Java, this becomes: /** * Print all the divisors of N. * We assume that N is a positive integer. */ static void printDivisors( int N ) { int D; // One of the possible divisors of N. System.out.println("The divisors of " + N + " are:"); for ( D = 1; D = 65) return ’C’; // 65 to 79 gets a C else if (numGrade >= 50) return ’D’; // 50 to 64 gets a D else
137
4.4. RETURN VALUES return ’F’; }
// anything else gets an F
// end of function letterGrade
The type of the return value of letterGrade() is char. Functions can return values of any type at all. Here’s a function whose return value is of type boolean. It demonstrates some interesting programming points, so you should read the comments: /** * The function returns true if N is a prime number. A prime number * is an integer greater than 1 that is not divisible by any positive * integer, except itself and 1. If N has any divisor, D, in the range * 1 < D < N, then it has a divisor in the range 2 to Math.sqrt(N), namely * either D itself or N/D. So we only test possible divisors from 2 to * Math.sqrt(N). */ static boolean isPrime(int N) { int divisor;
// A number we will test to see whether it evenly divides N.
if (N 0 print3NSequence(K); } while (K > 0); // continue only if K > 0 } // end main /** * print3NSequence prints a 3N+1 sequence to standard output, using
139
4.4. RETURN VALUES * startingValue as the initial value of N. It also prints the number * of terms in the sequence. The value of the parameter, startingValue, * must be a positive integer. */ static void print3NSequence(int startingValue) { int N; int count; int onLine;
// One of the terms in the sequence. // The number of terms found. // The number of terms that have been output // so far on the current line.
N = startingValue; count = 1;
// Start the sequence with startingValue; // We have one term so far.
TextIO.putln("The 3N+1 sequence starting from " + N); TextIO.putln(); TextIO.put(N, 8); // Print initial term, using 8 characters. onLine = 1; // There’s now 1 term on current output line. while (N > 1) { N = nextN(N); // compute next term count++; // count this term if (onLine == 5) { // If current output line is full TextIO.putln(); // ...then output a carriage return onLine = 0; // ...and note that there are no terms // on the new line. } TextIO.putf("%8d", N); // Print this term in an 8-char column. onLine++; // Add 1 to the number of terms on this line. } TextIO.putln(); // end current line of output TextIO.putln(); // and then add a blank line TextIO.putln("There were " + count + " terms in the sequence."); }
// end of Print3NSequence
/** * nextN omputes and returns the next term in a 3N+1 sequence, * given that the current term is currentN. */ static int nextN(int currentN) { if (currentN % 2 == 1) return 3 * currentN + 1; else return currentN / 2; } // end of nextN() } // end of class ThreeN2
You should read this program carefully and try to understand how it works. (Try using 27 for the starting value!)
140
4.5
CHAPTER 4. SUBROUTINES
APIs, Packages, and Javadoc
As
computers and their user interfaces have become easier to use, they have also become more complex for programmers to deal with. You can write programs for a simple console-style user interface using just a few subroutines that write output to the console and read the user’s typed replies. A modern graphical user interface, with windows, buttons, scroll bars, menus, text-input boxes, and so on, might make things easier for the user, but it forces the programmer to cope with a hugely expanded array of possibilities. The programmer sees this increased complexity in the form of great numbers of subroutines that are provided for managing the user interface, as well as for other purposes.
4.5.1
Toolboxes
Someone who wants to program for Macintosh computers—and to produce programs that look and behave the way users expect them to—must deal with the Macintosh Toolbox, a collection of well over a thousand different subroutines. There are routines for opening and closing windows, for drawing geometric figures and text to windows, for adding buttons to windows, and for responding to mouse clicks on the window. There are other routines for creating menus and for reacting to user selections from menus. Aside from the user interface, there are routines for opening files and reading >
The width here is specified as 50% of the available space, meaning a line that extends halfway across the page. The width could also be given as a fixed number of pixels. Many tags require matching closing tags, which take the form
For example, the tag at the beginning of an HTML document must be matched by a closing tag at the end of the document. As another example, the tag must always have a matching closing tag later in the document. An opening/closing tag pair applies to everything that comes between the opening tag and the closing tag. The tag tells a Web browser to display everything between the and the just as it is formatted in the original HTML source code, including all the spaces and carriage returns. (But tags between and are still interpreted by the browser.) “Pre” stands for preformatted text. All of the sample programs in the on-line version of this book are formatted using the command. It is important for you to understand that when you don’t use , the computer will completely ignore the formatting of the text in the HTML source code. The only thing it pays attention to is the tags. Five blank lines in the source code have no more effect than one blank line or even a single blank space. Outside of , if you want to force a new line on the Web page, you can use the tag
, which stands for “break”. For example, I might give my address as: David Eck
Department of Mathematics and Computer Science
Hobart and William Smith Colleges
Geneva, NY 14456
If you want extra vertical space in your web page, you can use several
’s in a row. Similarly, you need a tag to indicate how the text should be broken up into paragraphs. This is done with the
tag, which should be placed at the beginning of every paragraph. The
tag has a matching
, which should be placed at the end of each paragraph. The closing is technically optional, but it is considered good form to use it. If you want all the lines of the paragraph to be shoved over to the right, you can use
instead of
237
6.2. APPLETS AND HTML
. (This is mostly useful when used with one short line, or when used with
to make several short lines.) You can also use
for centered lines. By the way, if tags like
and have special meanings in HTML, you might wonder how one can get them to appear literally on a web page. To get certain special characters to appear on the page, you have to use an entity name in the HTML source code. The entity name for < is is >. Entity names begin with & and end with a semicolon. The character & is itself a special character whose entity name is &. There are also entity names for nonstandard characters such as an accented “e”, which has the entity name é. There are several useful tags that change the appearance of text. For example, to get italic text, enclose the text between and . For example, Introduction to Programming using Java
in an HTML document gives Introduction to Programming using Java in italics when the document is displayed as a Web page. Similarly, the tags , , and can be used for bold, underlined, and typewriter-style (“monospace”) text. A headline, with very large text, can be made placing the the text between and . Headlines with smaller text can be made using or instead of . Note that these headline tags stand on their own; they are not use inside paragraphs. You can add the modifier align=center to center the headline, and you can include break tags (
) in a headline to break it up into multiple lines. For example, the following HTML code will produce a medium–sized, centered, two-line headline: Chapter 6:
Introduction to GUI Programming
∗ ∗ ∗ The most distinctive feature of HTML is that documents can contain links to other documents. The user can follow links from page to page and in the process visit pages from all over the Internet. The tag is used to create a link. The text between the and its matching appears on the page as the text of the link; the user can follow the link by clicking on this text. The tag uses the modifier href to say which document the link should connect to. The value for href must be a URL (Uniform Resource Locator). A URL is a coded set of instructions for finding a document on the Internet. For example, the URL for my own “home page” is http://math.hws.edu/eck/
To make a link to this page, I would use the HTML source code David’s Home Page
The best place to find URLs is on existing Web pages. Web browsers display the URL for the page you are currently viewing, and they can display the URL of a link if you point to the link with the mouse. If you are writing an HTML document and you want to make a link to another document that is in the same directory, you can use a relative URL. The relative URL consists of just the name of the file. For example, to create a link to a file named “s1.html” in the same directory as the HTML document that you are writing, you could use Section 1
238
CHAPTER 6. INTRODUCTION TO GUI PROGRAMMING
There are also relative URLs for linking to files that are in other directories. Using relative URLs is a good idea, since if you use them, you can move a whole collection of files without changing any of the links between them (as long as you don’t change the relative locations of the files). When you type a URL into a Web browser, you can omit the “http://” at the beginning of the URL. However, in an tag in an HTML document, the “http://” can only be omitted if the URL is a relative URL. For a normal URL, it is required.
∗ ∗ ∗ You can add images to a Web page with the tag. (This is a tag that has no matching closing tag.) The actual image must be stored in a separate file from the HTML document. The tag has a required modifier, named src, to specify the URL of the image file. For most browsers, the image should be in one of the formats PNG (with a file name ending in “.png”), JPEG (with a file name ending in “.jpeg” or “.jpg”), or GIF (with a file name ending in “.gif”). Usually, the image is stored in the same place as the HTML document, and a relative URL—that is, just the name of the image file—is used to specify the image file. The tag also has several optional modifiers. It’s a good idea to always include the height and width modifiers, which specify the size of the image in pixels. Some browsers handle images better if they know in advance how big they are. The align modifier can be used to affect the placement of the image: “align=right” will shove the image to the right edge of the page, and the text on the page will flow around the image; “align=left” works similarly. (Unfortunately, “align=center” doesn’t have the meaning you would expect. Browsers treat images as if they are just big characters. Images can occur inside paragraphs, links, and headings, for example. Alignment values of center, top, and bottom are used to specify how the image should line up with other characters in a line of text: Should the baseline of the text be at the center, the top, or the bottom of the image? Alignment values of right and left were added to HTML later, but they are the most useful values. If you want an image centered on the page, put it inside a
tag.) For example, here is HTML code that will place an image from a file named figure1.png on the page.
The image is 100 pixels wide and 150 pixels high, and it will appear on the right edge of the page.
6.2.4
Applets on Web Pages
The main point of this whole discussion of HTML is to learn how to use applets on the Web. The tag can be used to add a Java applet to a Web page. This tag must have a matching . A required modifier named code gives the name of the compiled class file that contains the applet class. The modifiers height and width are required to specify the size of the applet, in pixels. If you want the applet to be centered on the page, you can put the applet in a paragraph with center alignment So, an applet tag to display an applet named HelloWorldApplet centered on a Web page would look like this:
239
6.2. APPLETS AND HTML
This assumes that the file HelloWorldApplet.class is located in the same directory with the HTML document. If this is not the case, you can use another modifier, codebase, to give the URL of the directory that contains the class file. The value of code itself is always just a class, not a URL. If the applet uses other classes in addition to the applet class itself, then those class files must be in the same directory as the applet class (always assuming that your classes are all in the “default package”; see Subsection 2.6.4). If an applet requires more than one or two class files, it’s a good idea to collect all the class files into a single jar file. Jar files are “archive files” which hold a number of smaller files. If your class files are in a jar archive, then you have to specify the name of the jar file in an archive modifier in the tag, as in
11.6. A BRIEF INTRODUCTION TO XML
597
false true
The first line, which is optional, merely identifies this as an XML document. This line can also specify other information, such as the character encoding that was used to encode the characters in the document into binary form. If this document had an associated DTD, it would be specified in a “DOCTYPE” directive on the next line of the file. Aside from the first line, the document is made up of elements, attributes, and textual content. An element starts with a tag , such as and ends with a matching end-tag such as . Between the tag and end-tag is the content of the element, which can consist of text and nested elements. (In the example, the only textual content is the true or false in the elements.) If an element has no content, then the opening tag and end-tag can be combined into a single empty tag , such as , which is an abbreviation for . A tag can include attributes such as the x and y in or the version in . A document can also include a few other things, such as comments, that I will not discuss here. The basic structure should look familiar to someone familiar with HTML. The most striking difference is that in XML, you get to choose the tags. Whereas HTML comes with a fixed, finite set of tags, with XML you can make up meaningful tag names that are appropriate to your application and that describe the >, the end-tag , and everything in between. The elements that are nested inside the root element are represented by their own nodes, which are said to be children of the root node. An object of type Element contains several useful methods. If element is of type Element, then we have: • element.getTagName() — returns a String containing the name that is used in the element’s tag. For example, the name of a element is the string “curve”. • element.getAttribute(attrName) — if attrName is the name of an attribute in the element, then this method returns the value of that attribute. For the element, , element.getAttribute("x") would return the string “83”. Note that the return value is always a String, even if the attribute is supposed to represent a numerical value. If the element has no attribute with the specified name, then the return value is an empty string. • element.getTextContent() — returns a String containing all the textual content that is contained in the element. Note that this includes text that is contained inside other elements that are nested inside the element. • element.getChildNodes() — returns a value of type NodeList that contains all the Nodes that are children of the element. The list includes nodes representing other elements and textual content that are directly nested in the element (as well as some other types of node that I don’t care about here). The getChildNodes() method makes it possible to traverse the entire DOM ?>
(This is just an easy exercise in simple XML processing; as before, the program in this exercise is not meant to be a useful phone directory program.) 6. The sample program Checkers.java from Subsection 7.5.3 lets two players play checkers. It would be nice if, in the middle of a game, the state of the game could be saved to a file. Later, the file could be read back into the file to restore the game and allow the players to continue. Add the ability to save and load files to the checkers program. Design a simple text-based format for the files. Here is a picture of my solution to this exercise, just after a file has been loaded into the program:
Note: The original checkers program could be run as either an applet or a stand-alone application. Since the new version uses files, however, it can only be run as an application. An applet running in a web browser is not allowed to access files. It’s a little tricky to completely restore the state of a game. The program has a variable board of type CheckersData that stores the current contents of the board, and it has a variable currentPlayer of type int that indicates whether Red or Black is currently moving. This data must be stored in the file when a file is saved. When a file is read into the program, you should read the data into two local variables newBoard of type CheckersData and newCurrentPlayer of type int. Once you have successfully read all the data from the file, you can use the following code to set up the program state correctly. This code assumes that you have introduced two new variables saveButton and loadButton of type JButton to represent the “Save Game” and “Load Game” buttons:
608
CHAPTER 11. FILES AND NETWORKING board = newBoard; // Set up game with data read from file. currentPlayer = newCurrentPlayer; legalMoves = board.getLegalMoves(currentPlayer); selectedRow = -1; gameInProgress = true; newGameButton.setEnabled(false); loadButton.setEnabled(false); saveButton.setEnabled(true); resignButton.setEnabled(true); if (currentPlayer == CheckersData.RED) message.setText("Game loaded -- it’s RED’s move."); else message.setText("Game loaded -- it’s BLACK’s move."); repaint();
(Note, by the way, that I used a TextReader to read the data from the file into my program. TextReader is a non-standard class introduced in Subsection 11.1.4 and defined in the file TextReader.java. How to read the data in a file depends, of course, on the format that you have chosen for the data.)
609
Quiz
Quiz on Chapter 11 1. In Java, input/output is done using streams. Streams are an abstraction. Explain what this means and why it is important. 2. Java has two types of streams: character streams and byte streams. Why? What is the difference between the two types of streams? 3. What is a file? Why are files necessary? 4. What is the point of the following statement? out = new PrintWriter( new FileWriter("data.dat") );
Why would you need a statement that involves two different stream classes, PrintWriter and FileWriter ? 5. The package java.io includes a class named URL. What does an object of type URL represent, and how is it used? 6. Explain what is meant by the client / server model of network communication. 7. What is a socket? 8. What is a ServerSocket and how is it used? 9. Network server programs are often multithreaded. Explain what this means and why it is true. 10. What is meant by an element in an XML document? 11. What is it about XML that makes it suitable for representing almost any type of data? 12. Write a complete program that will display the first ten lines from a text file. The lines should be written to standard output, System.out. The file name is given as the commandline argument args[0]. You can assume that the file contains at least ten lines. Don’t bother to make the program robust. Do not use TextIO to process the file; use a FileReader to access the file.
610
CHAPTER 11. FILES AND NETWORKING
Chapter 12
Advanced GUI Programming It’s possible to program a wide variety of GUI applications using only the techniques covered in Chapter 6. In many cases, the basic events, components, layouts, and graphics routines covered in that chapter suffice. But the Swing graphical user interface library is far richer than what we have seen so far, and it can be used to build highly sophisticated applications. This chapter is a further introduction to Swing and other aspects of GUI programming. Although the title of the chapter is “Advanced GUI Programming,” it is still just an introduction. Full coverage of this topic would require at least another complete book.
12.1
Images and Resources
We have seen how to use the Graphics class to draw on a GUI component that is visible on the computer’s screen. Often, however, it is useful to be able to create a drawing off-screen, in the computer’s memory. It is also important to be able to work with images that are stored in files. To a computer, an image is just a set of numbers. The numbers specify the color of each pixel in the image. The numbers that represent the image on the computer’s screen are stored in a part of memory called a frame buffer . Many times each second, the computer’s video card reads the data in the frame buffer and colors each pixel on the screen according to that data. Whenever the computer needs to make some change to the screen, it writes some new numbers to the frame buffer, and the change appears on the screen a fraction of a second later, the next time the screen is redrawn by the video card. Since it’s just a set of numbers, the data for an image doesn’t have to be stored in a frame buffer. It can be stored elsewhere in the computer’s memory. It can be stored in a file on the computer’s hard disk. Just like any other data file, an image file can be downloaded over the Internet. Java includes standard classes and subroutines that can be used to copy image data from one part of memory to another and to get data from an image file and use it to display the image on the screen.
12.1.1
Images and BufferedImages
The class java.awt.Image represents an image stored in the computer’s memory. There are two fundamentally different types of Image. One kind represents an image read from a source outside the program, such as from a file on the computer’s hard disk or over a network connection. The second type is an image created by the program. I refer to this second type as an off-screen canvas. An off-screen canvas is region of the computer’s memory that can be used as a drawing 611
612
CHAPTER 12. ADVANCED GUI PROGRAMMING
surface. It is possible to draw to an offscreen image using the same Graphics class that is used for drawing on the screen. An Image of either type can be copied onto the screen (or onto an off-screen canvas) using methods that are defined in the Graphics class. This is most commonly done in the paintComponent() method of a JComponent. Suppose that g is the Graphics object that is provided as a parameter to the paintComponent() method, and that img is of type Image. Then the statement g.drawImage(img, x, y, this);
will draw the image img in a rectangular area in the component. The integer-valued parameters x and y give the position of the upper-left corner of the rectangle in which the image is displayed, and the rectangle is just large enough to hold the image. The fourth parameter, this, is the special variable from Subsection 5.6.1 that refers to the JComponent itself. This parameter is there for technical reasons having to do with the funny way Java treats image files. For most applications, you don’t need to understand this, but here is how it works: g.drawImage() does not actually draw the image in all cases. It is possible that the complete image is not available when this method is called; this can happen, for example, if the image has to be read from a file. In that case, g.drawImage() merely initiates the drawing of the image and returns immediately. Pieces of the image are drawn later, asynchronously, as they become available. The question is, how do they get drawn? That’s where the fourth parameter to the drawImage method comes in. The fourth parameter is something called an ImageObserver. When a piece of the image becomes available to be drawn, the system will inform the ImageObserver, and that piece of the image will appear on the screen. Any JComponent object can act as an ImageObserver. The drawImage method returns a boolean value to indicate whether the image has actually been drawn or not when the method returns. When drawing an image that you have created in the computer’s memory, or one that you are sure has already been completely loaded, you can set the ImageObserver parameter to null. There are a few useful variations of the drawImage() method. For example, it is possible to scale the image as it is drawn to a specified width and height. This is done with the command g.drawImage(img, x, y, width, height, imageObserver);
The parameters width and height give the size of the rectangle in which the image is displayed. Another version makes it possible to draw just part of the image. In the command: dest y1, dest x2, dest y2, g.drawImage(img, dest x1, source x1, source y1, source x2, source y2, imageObserver);
the integers source x1, source y1, source x2, and source y2 specify the top-left and bottomright corners of a rectangular region in the source image. The integers dest x1, dest y1, dest x2, and dest y2 specify the corners of a region in the destination graphics context. The specified rectangle in the image is drawn, with scaling if necessary, to the specified rectangle in the graphics context. For an example in which this is useful, consider a card game that needs to display 52 different cards. Dealing with 52 image files can be cumbersome and inefficient, especially for downloading over the Internet. So, all the cards might be put into a single image:
12.1. IMAGES AND RESOURCES
613
(This image is from the Gnome desktop project, http://www.gnome.org, and is shown here much smaller than its actual size.) Now, only one Image object is needed. Drawing one card means drawing a rectangular region from the image. This technique is used in a variation of the sample program HighLowGUI.java from Subsection 6.7.6. In the original version, the cards are represented by textual descriptions such as “King of Hearts.” In the new version, HighLowWithImages.java, the cards are shown as images. An applet version of the program can be found in the on-line version of this section. In the program, the cards are drawn using the following method. The instance variable cardImages is a variable of type Image that represents the image that is shown above, containing 52 cards, plus two Jokers and a face-down card. Each card is 79 by 123 pixels. These numbers are used, together with the suit and value of the card, to compute the corners of the source rectangle for the drawImage() command: /** * Draws a card in a 79x123 pixel rectangle with its * upper left corner at a specified point (x,y). Drawing the card * requires the image file "cards.png". * @param g The graphics context used for drawing the card. * @param card The card that is to be drawn. If the value is null, then a * face-down card is drawn. * @param x the x-coord of the upper left corner of the card * @param y the y-coord of the upper left corner of the card */ public void drawCard(Graphics g, Card card, int x, int y) { int cx; // x-coord of upper left corner of the card inside cardsImage int cy; // y-coord of upper left corner of the card inside cardsImage if (card == null) { cy = 4*123; // coords for a face-down card. cx = 2*79; } else {
614
CHAPTER 12. ADVANCED GUI PROGRAMMING cx = (card.getValue()-1)*79; switch (card.getSuit()) { case Card.CLUBS: cy = 0; break; case Card.DIAMONDS: cy = 123; break; case Card.HEARTS: cy = 2*123; break; default: // spades cy = 3*123; break; } } g.drawImage(cardImages,x,y,x+79,y+123,cx,cy,cx+79,cy+123,this); }
I will tell you later in this section how the image file, cards.png, can be loaded into the program.
∗ ∗ ∗ In addition to images loaded from files, it is possible to create images by drawing to an off-screen canvas. An off-screen canvas can be represented by an object belonging to the class BufferedImage, which is defined in the package java.awt.image. BufferedImage is a subclass of Image, so that once you have a BufferedImage, you can copy it into a graphics context g using one of the g.drawImage() methods, just as you would do with any other image. A BufferedImage can be created using the constructor public BufferedImage(int width, int height, int imageType)
where width and height specify the width and height of the image in pixels, and imageType can be one of several constants that are defined in the BufferedImage. The image type specifies how the color of each pixel is represented. The most likely value for imageType is BufferedImage.TYPE INT RGB, which specifies that the color of each pixel is a usual RGB color, with red, green and blue components in the range 0 to 255. The image type BufferedImage.TYPE INT ARGB represents an RGB image with “transparency”; see the next section for more information on this. The image type BufferedImage.TYPE BYTE GRAY can be used to create a grayscale image in which the only possible colors are shades of gray. To draw to a BufferedImage, you need a graphics context that is set up to do its drawing on the image. If OSC is of type BufferedImage, then the method OSC.getGraphics()
returns an object of type Graphics that can be used for drawing on the image. There are several reasons why a programmer might want to draw to an off-screen canvas. One is to simply keep a copy of an image that is shown on the screen. Remember that a picture that is drawn on a component can be lost, for example when the component is covered by another window. This means that you have to be able to redraw the picture on demand, and that in turn means keeping enough information around to enable you to redraw the picture. One way to do this is to keep a copy of the picture in an off-screen canvas. Whenever the onscreen picture needs to be redrawn, you just have to copy the contents of the off-screen canvas onto the screen. Essentially, the off-screen canvas allows you to save a copy of the color of every
12.1. IMAGES AND RESOURCES
615
individual pixel in the picture. The sample program PaintWithOffScreenCanvas.java is a little painting program that uses an off-screen canvas in this way. In this program, the user can draw curves, lines, and various shapes; a “Tool” menu allows the user to select the thing to be drawn. There is also an “Erase” tool and a “Smudge” tool that I will get to later. A BufferedImage is used to store the user’s picture. When the user changes the picture, the changes are made to the image, and the changed image is then copied to the screen. No record is kept of the shapes that the user draws; the only record is the color of the individual pixels in the off-screen image. (You should contrast this with the program SimplePaint2.java in Subsection 7.3.4, where the user’s drawing is recorded as a list of objects that represent the shapes that user drew.) You should try the program (or the applet version in the on-line version of this section). Try drawing a Filled Rectangle on top of some other shapes. As you drag the mouse, the rectangle stretches from the starting point of the mouse drag to the current mouse location. As the mouse moves, the underlying picture seems to be unaffected—parts of the picture can be covered up by the rectangle and later uncovered as the mouse moves, and they are still there. What this means is that the rectangle that is shown as you drag the mouse can’t actually be part of the off-screen canvas, since drawing something into an image means changing the color of some pixels in the image. The previous colors of those pixels are not stored anywhere else and so are permanently lost. In fact, when you draw a line, rectangle, or oval in PaintWithOffScreenCanvas, the shape that is shown as you drag the mouse is not drawn to the off-screen canvas at all. Instead, the paintComponent() method draws the shape on top of the contents of the canvas. Only when you release the mouse does the shape become a permanent part of the off-screen canvas. This illustrates the point that when an off-screen canvas is used, not everything that is visible on the screen has to be drawn on the canvas. Some extra stuff can be drawn on top of the contents of the canvas by the paintComponent() method. The other tools are handled differently from the shape tools. For the curve, erase, and smudge tools, the changes are made to the canvas immediately, as the mouse is being dragged. Let’s look at how an off-screen canvas is used in this program. The canvas is represented by an instance variable, OSC, of type BufferedImage. The size of the canvas must be the same size as the panel on which the canvas is displayed. The size can be determined by calling the getWidth() and getHeight() instance methods of the panel. Furthermore, when the canvas is first created, it should be filled with the background color, which is represented in the program by an instance variable named fillColor. All this is done by the method: /** * This method creates the off-screen canvas and fills it with the current * fill color. */ private void createOSC() { OSC = new BufferedImage(getWidth(),getHeight(),BufferedImage.TYPE INT RGB); Graphics osg = OSC.getGraphics(); osg.setColor(fillColor); osg.fillRect(0,0,getWidth(),getHeight()); osg.dispose(); }
Note how it uses OSC.getGraphics() to obtain a graphics context for drawing to the image. Also note that the graphics context is disposed at the end of the method. It is good practice to dispose a graphics context when you are finished with it. There still remains the problem of where to call this method. The problem is that the width and height of the panel object are not set until some time after the panel object is constructed. If createOSC() is called in
616
CHAPTER 12. ADVANCED GUI PROGRAMMING
the constructor, getWidth() and getHeight() will return the value zero and we won’t get an off-screen image of the correct size. The approach that I take in PaintWithOffScreenCanvas is to call createOSC() in the paintComponent() method, the first time the paintComponent() method is called. At that time, the size of the panel has definitely been set, but the user has not yet had a chance to draw anything. With this in mind you are ready to understand the paintComponent() method: public void paintComponent(Graphics g) { /* First create the off-screen canvas, if it does not already exist. */ if (OSC == null) createOSC(); /* Copy the off-screen canvas to the panel. Since we know that the image is already completely available, the fourth "ImageObserver" parameter to g.drawImage() can be null. Since the canvas completely fills the panel, there is no need to call super.paintComponent(g). */ g.drawImage(OSC,0,0,null); /* If the user is currently dragging the mouse to draw a line, oval, or rectangle, draw the shape on top of the image from the off-screen canvas, using the current drawing color. (This is not done if the user is drawing a curve or using the smudge tool or the erase tool.) */ if (dragging && SHAPE TOOLS.contains(currentTool)) { g.setColor(currentColor); putCurrentShape(g); } }
Here, dragging is a boolean instance variable that is set to true while the user is dragging the mouse, and currentTool tells which tool is currently in use. The possible tools are defined by an enum name Tool, and SHAPE TOOLS is a variable of type EnumSet that contains the line, oval, rectangle, filled oval, and filled rectangle tools. (See Subsection 10.2.4.) You might notice that there is a problem if the size of the panel is ever changed, since the size of the off-screen canvas will not be changed to match. The PaintWithOffScreenCanvas program does not allow the user to resize the program’s window, so this is not an issue in that program. If we want to allow resizing, however, a new off-screen canvas must be created whenever the size of the panel changes. One simple way to do this is to check the size of the canvas in the paintComponent() method and to create a new canvas if the size of the canvas does not match the size of the panel: if (OSC == null || getWidth() != OSC.getWidth() || getHeight() != OSC.getHeight()) createOSC();
Of course, this will discard the picture that was contained in the old canvas unless some arrangement is made to copy the picture from the old canvas to the new one before the old canvas is discarded. The other point in the program where the off-screen canvas is used is during a mouse-drag operation, which is handled in the mousePressed(), mouseDragged(), and mouseReleased() methods. The strategy that is implemented was discussed above. Shapes are drawn the offscreen canvas at the end of the drag operation, in the mouseReleased() method. However,
617
12.1. IMAGES AND RESOURCES
as the user drags the mouse, the part of the image where the shape appears is redrawn each time the mouse is moved; the shape that appears on the screen is drawn on top of the canvas by the paintComponent() method. For the other tools, changes are made directly to the canvas, and the region that was changed is repainted so that the change will appear on the screen. (By the way, the program uses a version of the repaint() method that repaints just a part of a component. The command repaint(x,y,width,height) tells the system to repaint the rectangle with upper left corner (x,y) and with the specified width and height. This can be substantially faster than repainting the entire component.) See the source code, PaintWithOffScreenCanvas.java, if you want to see how it’s all done.
∗ ∗ ∗ One traditional use of off-screen canvasses is for double buffering . In double-buffering, the off-screen image is an exact copy of the image that appears on screen. In double buffering, whenever the on-screen picture needs to be redrawn, the new picture is drawn step-by-step to an off-screen image. This can take some time. If all this drawing were done on screen, the user would see the image flicker as it is drawn. Instead, the long drawing process takes place off-screen and the completed image is then copied very quickly onto the screen. The user doesn’t see all the steps involved in redrawing. This technique can be used to implement smooth, flicker-free animation. The term “double buffering” comes from the term “frame buffer,” which refers to the region in memory that holds the image on the screen. In fact, true double buffering uses two frame buffers. The video card can display either frame buffer on the screen and can switch instantaneously from one frame buffer to the other. One frame buffer is used to draw a new image for the screen. Then the video card is told to switch from one frame buffer to the other. No copying of memory is involved. Double-buffering as it is implemented in Java does require copying, which takes some time and is not perfectly flicker-free. In Java’s older AWT graphical API, it was up to the programmer to do double buffering by hand. In the Swing graphical API, double buffering is applied automatically by the system, and the programmer doesn’t have to worry about it. (It is possible to turn this automatic double buffering off in Swing, but there is seldom a good reason to do so.) One final historical note about off-screen canvasses: There is an alternative way to create them. The Component class defines the following instance method, which can be used in any GUI component object: public Image createImage(int width, int height)
This method creates an Image with a specified width and height. You can use this image as an off-screen canvas in the same way that you would a BufferedImage. In fact, you can expect that in a modern version of Java, the image that is returned by this method is in fact a BufferedImage. The createImage() method was part of Java from the beginning, before the BufferedImage class was introduced.
12.1.2
Working With Pixels
One good reason to use a BufferedImage is that it allows easy access to the colors of individual pixels. If image is of type BufferedImage, then we have the methods: • image.getRGB(x,y) — returns an int that encodes the color of the pixel at coordinates (x,y) in the image. The values of the integers x and y must lie within the image. That is,
618
CHAPTER 12. ADVANCED GUI PROGRAMMING it must be true that 0 B is the integer obtained by shifting each bit of A B bit positions to the right; A & B is the integer obtained by applying the logical and operation to each pair of bits in A and B; and A | B is obtained similarly, using the logical or operation. For example, using 8-bit binary numbers, we have: 01100101 & 10100001 is 00100001, while 01100101 | 10100001 is 11100101.) You don’t necessarily need to understand these operators. Here are incantations that you can use to work with color codes: /* Suppose that rgb is an int that encodes a color. To get separate red, green, and blue color components: *; int red = (rgb >> 16) & 0xFF; int green = (rgb >> 8) & 0xFF; int blue = rgb & 0xFF; /* Suppose that red, green, and blue are color components in the range 0 to 255. To combine them into a single int: */ int rgb = (red = w) { // A -1 in the smudgeRed array indicates that the // corresponding pixel was outside the canvas. smudgeRed[i][j] = -1; } else { int color = OSC.getRGB(c,r); smudgeRed[i][j] = (color >> 16) & 0xFF; smudgeGreen[i][j] = (color >> 8) & 0xFF; smudgeBlue[i][j] = color & 0xFF; } }
The arrays are of type double[ ][ ] because I am going to do some computations with them that require real numbers. As the user moves the mouse, the colors in the array are blended with the colors in the image, just as if you were mixing wet paint by smudging it with your finger. That is, the colors at the new mouse position in the image are replaced with a weighted average of the current colors in the image and the colors in the arrays. This has the effect of moving some of the color from the previous mouse position to the new mouse position. At the same time, the colors in the arrays are replaced by a weighted average of the colors in the arrays and the colors from the image. This has the effect of moving some color from the image into the arrays. This is done using the following code for each pixel position, (c,r), in a 7-by-7 block around the new mouse location: int curCol = OSC.getRGB(c,r); int curRed = (curCol >> 16) & 0xFF; int curGreen = (curCol >> 8) & 0xFF; int curBlue = curCol & 0xFF; int newRed = (int)(curRed*0.7 + smudgeRed[i][j]*0.3); int newGreen = (int)(curGreen*0.7 + smudgeGreen[i][j]*0.3); int newBlue = (int)(curBlue*0.7 + smudgeBlue[i][j]*0.3); int newCol = newRed
