1. David Evans http://www.cs.virginia.edu/~evans
Lecture 2:
Java Semantics,
Validation
CS201j: Engineering Software?
University of Virginia
Computer Science
David Evans

2. Menu Survey Results Objects in Java: Heap and Stack
Validation: Testing and Analysis
29 August 2002
CS 201j Fall 2002

3. Survey Results
29 August 2002
CS 201j Fall 2002

4. Experience Almost everyone: C++ Only 2 with a little Java experience
Scheme, PHP, Python, Basic, VHDL
Largest Program:
16: CS101/CS200 (few hundred lines)
5 people had experience with line programs
Only 4 of you did any programming over the summer!
29 August 2002
CS 201j Fall 2002

5. Other Answers On the course web site My answers also… 29 August 2002
CS 201j Fall 2002

6. Java Semantics
29 August 2002
CS 201j Fall 2002

7. The Stack and Heap String s = new String (“hello”); s
java.lang.String
String is a type in the Java API for representing sequences of characters
“hello”
Objects live on the Heap
new creates an Object on the Heap
Local variables live on the Stack
Point to objects on the Heap
29 August 2002
CS 201j Fall 2002

8. String s = new String (“hello”);
String t = s; s
java.lang.String t
“hello”
29 August 2002
CS 201j Fall 2002

9. String s = new String (“hello”);
String t = s; s
java.lang.String
java.lang.String t
“hello”
“goodbye”
s = new String
(“goodbye”);
29 August 2002
CS 201j Fall 2002

10. Primitive Types Not everything in Java is an Object
Some types are primitive types
boolean, byte, char, double, float, int, long, short
Values of primitive types are stored directly on the stack
29 August 2002
CS 201j Fall 2002

11. String s = new String (“hello”);
String t = s;
int i = 201; s
int j = i;
java.lang.String t
“hello” i
201 j
201
How can we see the difference between
primitive types and objects?
29 August 2002
CS 201j Fall 2002

12. Equality x == y Object Types: same objects Primitive Types: same value
x.equals (y)
Object Types: method that compares values of objects
Primitive Types: doesn’t exist
29 August 2002
CS 201j Fall 2002

13. Mutability
If an object is mutated, all references to the object see the new value
StringBuffer sb = new (“hi”);
StringBuffer tb = sb;
tb.append (“gh”); sb
java.lang.StringBuffer tb
“hi”
“high”
29 August 2002
CS 201j Fall 2002

14. Immutable/Mutable Types
Types can be mutable or immutable
Objects of an immutable type never change value after they are created
String is immutable, StringBuffer is mutable
String.concat creates a new String object
StringBuffer.append mutates the old object
29 August 2002
CS 201j Fall 2002

15. Java Semantics Question
public class Strings {
public static void test (String [] args) {
String s = new String ("hello");
String t = new String ("hello");
StringBuffer sb = new StringBuffer ("he");
StringBuffer tb = sb;
String s1 = "hello";
String t1 = "hello";
sb.append (“llo");
tb.append (" goodbye!");
s.concat (" goodbye!");
t = s.concat (" goodbye!");
// What are the values of s, t, sb and tb now?
// Which of these are true:
// a) s == t b) s1 == t1 c) s == s1
// d) s.equals (t) e) sb == tb f) t.equals (tb) }
java.lang.String
“hello” s
java.lang.String t
“hello” sb
201 tb
201
29 August 2002
CS 201j Fall 2002

16. Java Semantics Question
public class Strings {
public static void test () {
String s = new String ("hello");
String t = new String ("hello");
StringBuffer sb = new StringBuffer ("he");
StringBuffer tb = sb;
String s1 = "hello";
String t1 = "hello";
sb.append (“llo");
tb.append (" goodbye!");
s.concat (" goodbye!");
t = s.concat (" goodbye!"); } }
java.lang.String
“hello” s
java.lang.String t
“hello” sb
java.lang.StringBuffer tb
“he” s1
String spec is not enough to
determine if s, t, s1 and t1 are
the same objects! This is what
Sun’s JDK 1.4 does. Other implementations could correctly do different things.
java.lang.String t1
“hello”
29 August 2002
CS 201j Fall 2002

17. Java Semantics Question
public class Strings {
public static void test () {
String s = new String ("hello");
String t = new String ("hello");
StringBuffer sb = new StringBuffer ("he");
StringBuffer tb = sb;
String s1 = "hello";
String t1 = "hello";
sb.append (“llo");
tb.append (" goodbye!");
s.concat (" goodbye!");
t = s.concat (" goodbye!"); } }
java.lang.String
“hello” s
java.lang.String t
“hello” sb
java.lang.StringBuffer tb
“he”
“hello” s1
java.lang.String t1
“hello”
29 August 2002
CS 201j Fall 2002

18. Java Semantics Question
public class Strings {
public static void test () {
String s = new String ("hello");
String t = new String ("hello");
StringBuffer sb = new StringBuffer ("he");
StringBuffer tb = sb;
String s1 = "hello";
String t1 = "hello";
sb.append (“llo");
tb.append (" goodbye!");
s.concat (" goodbye!");
t = s.concat (" goodbye!"); } }
java.lang.String
“hello” s
java.lang.String t
“hello” sb
java.lang.StringBuffer tb
“he”
“hello goodbye!” s1
java.lang.String t1
“hello”
29 August 2002
CS 201j Fall 2002

19. Java Semantics Question
public class Strings {
public static void test () {
String s = new String ("hello");
String t = new String ("hello");
StringBuffer sb = new StringBuffer ("he");
StringBuffer tb = sb;
String s1 = "hello";
String t1 = "hello";
sb.append (“llo");
tb.append (" goodbye!");
s.concat (" goodbye!");
t = s.concat (" goodbye!"); } }
java.lang.String
“hello” s
java.lang.String t
“hello” sb
java.lang.StringBuffer tb
“he”
“hello goodbye!” s1
java.lang.String
java.lang.String t1
“hello”
“hello goodbye!”
29 August 2002
CS 201j Fall 2002

20. s t sb tb s1 t1 java.lang.String “hello goodbye!” java.lang.String
public class Strings {
public static void test () {
String s = new String ("hello");
String t = new String ("hello");
StringBuffer sb = new StringBuffer ("he");
StringBuffer tb = sb;
String s1 = "hello";
String t1 = "hello";
sb.append (“llo");
tb.append (" goodbye!");
s.concat (" goodbye!");
t = s.concat (" goodbye!"); } }
java.lang.String
“hello” s
java.lang.String t
“hello” sb
java.lang.StringBuffer tb
“he”
“hello goodbye!” s1
java.lang.String
java.lang.String t1
“hello”
“hello goodbye!”
29 August 2002
CS 201j Fall 2002

21. s t sb tb s1 t1 After test returns? java.lang.String “hello goodbye!”
public class Strings {
public static void test () {
String s = new String ("hello");
String t = new String ("hello");
StringBuffer sb = new StringBuffer ("he");
StringBuffer tb = sb;
String s1 = "hello";
String t1 = "hello";
sb.append (“llo");
tb.append (" goodbye!");
s.concat (" goodbye!");
t = s.concat (" goodbye!"); } }
java.lang.String
“hello” s
java.lang.String t
“hello” sb
java.lang.StringBuffer tb
“he”
“hello goodbye!” s1
java.lang.String
java.lang.String t1
“hello”
“hello goodbye!”
29 August 2002
CS 201j Fall 2002

22. Validation
29 August 2002
CS 201j Fall 2002

23. Dictionary Definition
val·i·date
To declare or make legally valid.
To mark with an indication of official sanction.
To establish the soundness of; corroborate.
Can we do any of these with software?
29 August 2002
CS 201j Fall 2002

24. Java’s License
READ THE TERMS OF THIS AGREEMENT AND ANY PROVIDED SUPPLEMENTAL LICENSE TERMS (COLLECTIVELY "AGREEMENT") CAREFULLY BEFORE OPENING THE SOFTWARE MEDIA PACKAGE.  BY OPENING THE SOFTWARE MEDIA PACKAGE, YOU AGREE TO THE TERMS OF THIS AGREEMENT.  IF YOU ARE ACCESSING THE SOFTWARE ELECTRONICALLY, INDICATE YOUR ACCEPTANCE OF THESE TERMS BY SELECTING THE "ACCEPT" BUTTON AT THE END OF THIS AGREEMENT.  IF YOU DO NOT AGREE TO ALL THESE TERMS, PROMPTLY RETURN THE UNUSED SOFTWARE TO YOUR PLACE OF PURCHASE FOR A REFUND OR, IF THE SOFTWARE IS ACCESSED ELECTRONICALLY, SELECT THE "DECLINE" BUTTON AT THE END OF THIS AGREEMENT.
29 August 2002
CS 201j Fall 2002

25. Java’s License
5.  LIMITATION OF LIABILITY.  TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.  …
29 August 2002
CS 201j Fall 2002

26. Java’s License
2.  RESTRICTIONS.  … Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software.  You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility.  Sun disclaims any express or implied warranty of fitness for such uses. 
29 August 2002
CS 201j Fall 2002

27. Software Validation
Process designed to increase our confidence that a program works as intended
For complex programs, cannot often make guarantees
This is why typical software licenses don’t make any claims about their program working
29 August 2002
CS 201j Fall 2002

28. Increasing Confidence
Testing
Run the program on set of inputs and check the results
Verification
Argue formally or informally that the program always works as intended
Analysis
Poor programmer’s verification: examine the source code to increase confidence that it works as intended
29 August 2002
CS 201j Fall 2002

29. Testing
If all the test cases produce the correct results, you know that a particular execution of the program on each of the test cases produced the correct result
Concluding that this means the program is correct is like concluding there are no fish in the river because you didn’t catch one!
29 August 2002
CS 201j Fall 2002

30. Exhaustive Testing Test all possible inputs
PS1: 50x50 grid, all cells can be either dead or alive before starting
22500 =
But that’s not all: all possible start stop step interactions, different platforms, how long to you need to run it, etc.
29 August 2002
CS 201j Fall 2002

31. Selective Testing
We can’t test everything, pick test cases with high probability of finding flaws
Black-Box Testing: design tests looking only at specification
Glass-Box Testing: design tests looking at code
Path-complete: at least one test to exercise each path through code
29 August 2002
CS 201j Fall 2002

32. Black-Box Testing Test all paths through the specification:
public CellState getNextState ()
// MODIFIES: this
// EFFECTS: Returns the next state for this cell. If a cell is currently
// dead cell and has three live neighbors, then it becomes a live cell.
// If a cell is currently alive and has two or three live neighbors it
// remains alive. Otherwise, the cell dies.
Test all paths through the specification:
currently dead, three live neighbors
currently alive, two live neighbors
currently alive, three live neighbors
currently dead, < 3 live neighbors
currently dead, > 3 live neighbors
currently alive, < 2 live neighbors
currently alive, > 3 live neighbors
29 August 2002
CS 201j Fall 2002

33. Black-Box Testing Test all paths through the specification (7 tests)
public CellState getNextState ()
// MODIFIES: this
// EFFECTS: Returns the next state for this cell. If a cell is currently
// dead cell and has three live neighbors, then it becomes a live cell.
// If a cell is currently alive and has two or three live neighbors it
// remains alive. Otherwise, the cell dies.
Test all paths through the specification (7 tests)
Test boundary conditions
all neighbors are dead
all neighbors are alive
cell is at a corner of the grid
cell is at an edge of the grid
29 August 2002
CS 201j Fall 2002

34. Glass-Box Testing Test all paths through the code (4)
public CellState getNextState ()
// MODIFIES: this
// EFFECTS: Returns the next state for this cell. If a cell is currently
// dead cell and has three live neighbors, then it becomes a live cell.
// If a cell is currently alive and has two or three live neighbors it
// remains alive. Otherwise, the cell dies. {
if (countAliveNeighbors () == 3) {
return CellState.createAlive ();
} else if (getState ().isAlive () && countAliveNeighbors () == 2) {
} else {
return CellState.createDead (); }
Test all paths through the code (4)
29 August 2002
CS 201j Fall 2002

35. Glass-Box Testing Test all paths through the code (4)
public CellState getNextState ()
// MODIFIES: this
// EFFECTS: Returns the next state for this cell. If a cell is currently
// dead cell and has three live neighbors, then it becomes a live cell.
// If a cell is currently alive and has two or three live neighbors it
// remains alive. Otherwise, the cell dies. {
if (countAliveNeighbors () == 3) {
return CellState.createAlive ();
} else if (getState ().isAlive () && countAliveNeighbors () == 2) {
} else {
return CellState.createDead (); }
Test all paths through the code (4)
29 August 2002
CS 201j Fall 2002

36. Path-Complete Testing
Insufficient
Often, bugs are missing paths
Impossible
Most programs have essentially infinite number of paths
Loops and recursion
Test with zero, one and several iterations
29 August 2002
CS 201j Fall 2002

37. Testing Recap
Testing can find problems, not to prove your program works
Since exhaustive testing is impossible, select test cases with maximum probability of finding bugs
A successful test case is one that reveals a bug in your program!
Typically at least 40% of cost of software project is testing, often ~80% of cost for safety-critical software
29 August 2002
CS 201j Fall 2002

38. If we can’t test all possible paths through a program, how can we increase our confidence that it works?
29 August 2002
CS 201j Fall 2002

39. Analysis
Make claims about all possible paths by examining the program code directly, not executing it
Use formal semantics of programming language to know what things mean
Use formal specifications of procedures to know that they do
29 August 2002
CS 201j Fall 2002

40. Hopelessness of Analysis
It is impossible to correctly determine if any interesting property is true for an arbitrary program!
The Halting Problem: it is impossible to write a program that determines if an arbitrary program halts.
More on this later in the class…
29 August 2002
CS 201j Fall 2002

41. Compromises Accept unsoundness and incompleteness
False positives: sometimes an analysis tool will report warnings for a program, when the program is actually okay (unsoundness)
False negatives: sometimes an analysis tool will report no warnings for a program, even when the program violates properties it checks (incompleteness)
29 August 2002
CS 201j Fall 2002

42. ESC/Java Extended Static Checking for Java
Analysis tool developed at DEC/Compaq/HP Research Lab
Is unsound and incomplete:
Just because it finds no warnings, doesn’t mean your code is correct
PS2: use without adding annotations
Later: use annotations to document program assumptions
29 August 2002
CS 201j Fall 2002

43. CS201J Bug Bounty
If you find a bug in the code we provide, you get 10 bonus points.
If you find a bug in the Java compiler or API code, you get 50 bonus points.
If you find a bug in ESC/Java or the ESC/Java Specs, you get 5 bonus points.
29 August 2002
CS 201j Fall 2002

44. Charge Increase confidence a program works by:
Testing: sample possible executions, trying to find ones that don’t work
Analysis: check properties about all possible executions by examining code
PS2: a lot longer and harder than PS1
Remember to take pictures!
29 August 2002
CS 201j Fall 2002