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

2. Menu
• Objects in Java: Heap and Stack
• Validation: Testing and Analysis
2 September 2003 CS 201J Fall 2003 2

3. Java Semantics
2 September 2003 CS 201J Fall 2003 3

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

5. String s = new String
(“hello”);
String t = s;
s
java.lang.String
t
“hello”
2 September 2003 CS 201J Fall 2003 5

6. String s = new String
(“hello”);
String t = s;
s
java.lang.String java.lang.String
t
“hello”
“goodbye”
s = new String
(“goodbye”);
2 September 2003 CS 201J Fall 2003 6

7. 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
2 September 2003 CS 201J Fall 2003 7

8. String s = new String
(“hello”);
String t = s;
s
int i = 201;
java.lang.String int j = i;
t
“hello”
i 201
j 201
How can we see the difference between
primitive types and objects?
2 September 2003 CS 201J Fall 2003 8

9. 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
2 September 2003 CS 201J Fall 2003 9

10. 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
“high”
“hi”
2 September 2003 CS 201J Fall 2003 10

11. 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
2 September 2003 CS 201J Fall 2003 11

12. 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)
}
}
2 September 2003 CS 201J Fall 2003 12

13. Java Semantics Question
public class Strings {
public static void test () {
String s = new String ("hello"); java.lang.String
String t = new String ("hello");
StringBuffer sb = new StringBuffer “hello”
("he"); s
StringBuffer tb = sb; java.lang.String
String s1 = "hello";
String t1 = "hello";
t
“hello”
sb.append (“llo"); sb java.lang.StringBuffer
tb.append (" goodbye!");
s.concat (" goodbye!");
t = s.concat (" goodbye!"); } } tb “he”
String spec is not enough to s1 java.lang.String
determine if s, t, s1 and t1 are
the same objects! This is what t1 “hello”
Sun’s JDK 1.4 does. Other
implementations could correctly
do different things. Note (added Feb 2005): Nora Sovarel noticed that
this isn’t actually true. The JLS section on String
2 September 2003 CS 201J Fall specifies the behavior as shown.
literals 2003 13
http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#101083

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

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

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

17. java.lang.String
“hello goodbye!”
public class Strings {
public static void test () {
String s = new String ("hello"); java.lang.String
String t = new String ("hello");
StringBuffer sb = new StringBuffer “hello”
("he"); s
StringBuffer tb = sb; java.lang.String
String s1 = "hello";
String t1 = "hello";
t
“hello”
sb.append (“llo"); sb java.lang.StringBuffer
tb.append (" goodbye!");
s.concat (" goodbye!");
t = s.concat (" goodbye!"); } } tb “hello
“he”
goodbye!”
s1 java.lang.String
java.lang.String
“hello goodbye!”
t1 “hello”
2 September 2003 CS 201J Fall 2003 17

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

19. Validation
2 September 2003 CS 201J Fall 2003 19

20. Dictionary Definition
val·i·date
1. To declare or make legally valid.
2. To mark with an indication of official
sanction.
3. To establish the soundness of;
corroborate.
Can we do any of these with software?
2 September 2003 CS 201J Fall 2003 20

21. 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
2 September 2003 THIS CS 201J Fall 2003
THE END OF AGREEMENT. 21

22. 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. …
2 September 2003 CS 201J Fall 2003 22

23. 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.
2 September 2003 CS 201J Fall 2003 23

24. 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
2 September 2003 CS 201J Fall 2003 24

25. 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
2 September 2003 CS 201J Fall 2003 25

26. 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!
2 September 2003 CS 201J Fall 2003 26

27. Exhaustive Testing
• Test all possible inputs
• PS1: 50x50 grid, all cells can be either
dead or alive before starting
22500 =
3758280234548012036833624189723865048677365517592586770565238397822316814983377085357327257526588
4433370245774952605776030922789135161776565190731096878023646469404331623656214672441647859113183
2593729111221580180531749232777515579969899075142213969117994877343802049421624954402214529390781
6475633395350247725849016076668629825679186228496361602088773658349501637901885230262474405073903
8203218889238610990586970675314324392119848221207544402243336655478685655938968958563812658237722
4037721702239991441466026185752651502936472280911018500320375496336749951569521541850441747925844
0662952796718726052857925526601307020479982183347493563216774695296825517658582675027158940078877
27250070780350262952377214028842297486263597879792176338220932619489509376
But that’s not all: all possible start stop step interactions,
different platforms, how long to you need to run it, etc.
2 September 2003 CS 201J Fall 2003 27

28. 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
2 September 2003 CS 201J Fall 2003 28

29. Black-Box Testing
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:
1. currently dead, three live neighbors
2. currently alive, two live neighbors
3. currently alive, three live neighbors
4. currently dead, < 3 live neighbors
5. currently dead, > 3 live neighbors
6. currently alive, < 2 live neighbors
7. currently alive, >201J Fallneighbors
2 September 2003 CS
3 live 2003 29

30. Black-Box Testing
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
1. all neighbors are dead
2. all neighbors are alive
3. cell is at a corner of the grid
4. cell is at an edge of the grid
2 September 2003 CS 201J Fall 2003 30

31. Glass-Box Testing
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) {
return CellState.createAlive ();
} else {
return CellState.createDead ();
}
}
Test all paths through the code (4)
2 September 2003 CS 201J Fall 2003 31

32. 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
2 September 2003 CS 201J Fall 2003 32

33. 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
2 September 2003 CS 201J Fall 2003 33

34. 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
2 September 2003 CS 201J Fall 2003 34