1. Applets
   1. Applet life cycle:
   2. Writing Applets instead of applications
2. Impossible problems
3. Wrapping it all up
   1. Goals of the course:

Office Hours: Monday-Friday from 10-11am or by appointment

Applets

Applet life cycle:

public void init() - executed once when method starts up

Usually includes all code for layout and initialization of object creation

public void start() - executed after init & every time return to page containing applet

public void paint(Graphics g) - called after init and start to draw applet.
Called automatically anytime applet needs to be repainted

public void stop() - called to stop applet (usually not necessary)

public void destroy() - called when applet being removed from memory
- used to release or destroy any resources in use.

Calling paint problematic since usually don't have Graphics object in hand. Instead call repaint(); which invokes "update" method (passing it a Graphics object).

The update method erases any drawing done previously and then calls paint with the Graphics object.

Writing Applets instead of applications

1. Include: import java.applet.Applet;

2. Class should extend Applet rather than Frame;

3. Replace constructor by public void init(){...} method.

   Omit method calls to super, show, or setSize. Note that default layout manager for Applet is FlowLayout (rather than BorderLayout used by Frame) so may have to explicitly setLayout if desire layout different from FlowLayout.

4. Omit main static method.

   If no interaction with environment then can consider start() as the main program and call other methods from there. If applet works via interaction with environment then often omit start() or just have it reinitialize state so can start over.

5. Create web page with:
   <applet archive="JarName.jar" code="MainClass.class" width=140 height=200> </applet>

Impossible problems

Have I Got a DEAL for You!

Suppose someone wants to sell you a program that will enable you to stop wasting lots of time in your programs. They will sell you a program that will analyze any other program (before you run it) and tell you whether or not it will stop. Should you buy the program (or try to write it yourself)?

You try out the program on lots of your programs and it seems to work properly. Then you get the inspiration to try it out on one last program. Here is the program:

public class Debunk
{ 
	/* CharlatanType contains method halts, which takes a 
		filename as input and returns true iff the program 
		contained in that file is a legal Pascal program that 
		halts on empty input. */

	public static void what(String fileName)
	{
		CharlatanType charlatan = new CharlatanType(); 
		if (charlatan.halts(FileName))
		{
			while (true){}
		}
		// else halt
	}

	public static void main(String[] args)
	{
		what("Debunk.java");
	}
}

Following the usual style in Java, we name the file in which this program is stored, Debunk.java.

We begin executing the program Debunk, but in a few moments smoke starts rising from the computer, and after a few more minutes the machine grinds to a halt showing the frowning Mac face, never to run a program again.

What happened?

Let's analyze the program:

When what("Debunk.java") is executed, the first thing that happens is that Halts("Debunk.java") is called.

It will either return true or false. Look at the cases:

1. Suppose halts("Debunk.java") returns true (meaning the program in Debunk.java will eventually halt). Then the program goes into an infinite loop, never halting. Thus the program in Debunk.java will never halt. CONTRADICTION!

2. Suppose halts("Debunk.java") returns true (meaning the program in Debunk.java will not halt). Then the program immediately halts. Thus the program in Debunk.java will eventually halt. CONTRADICTION

What went wrong? The only possibility is that we couldn't possibly have such a program! In other words, without even looking at the code of halts, we have proved that it could not possibly work the way it claimed to. Thus no one could write such a program.

There are many such programs that would be useful to have that are not possible to write. This is discussed further in CS361, Theory of Computation.

Wrapping it all up

Goals of the course:

1. to introduce you to the basics of data structures and algorithm analysis. We emphasized the use of abstraction in designing classes. These techniques support the design of powerful new data structures and operations on them which can be treated as though they are primitive.

2. to introduce you to the object-oriented programming paradigm, which supports powerful and useful ways of thinking about and designing programs: classes, objects with instance variables and methods, inheritance and subtyping.
   Be aware there is still a lot you don't know about Java (and especially its libraries)!

3. to introduce you to interactive programming with the event-driven style of graphic user interfaces and provide a minimal intro to concurrency with threads.

Exam: 2 1/2 hours. Comprehensive with extra attention to topics since last exam:

Graphs, Dictionary, Concurrency.

Questions will be similar to those of midterm exams.