IPL. Java. 23 November 01.

IPL. Java. 23 November 01. Graphics. Threads. "Reflection".

[Stripped down versions of code below is here.]

0. Assignment: Please read chapters 13 on graphics and 14 on threads.

1. Graphics

Overview
- Java graphics programming generally involves a distinctive style of programming--that of "event-driven" programs. Instead of specifying a series of steps from program start to program finish, you wait for (unpredictable) user-generated events and then act on them. Programming in this idiom largely consists of indicating what to do in case the user selects a particular menu item, or clicks on a particular item in a dialog box, etc.
- As we'll see, there's a separation of the user-interface layer (what you see) from the event-logic layer (what it does).
- The built-in Java graphics libraries are enormous. The situation is complicated by the fact that the original Java graphics framework (AWT--the Abstract Window Toolkit) has been largely--but not completely--replaced by a newer framework, "Swing".
Architecture.
- Elements:
  - Components (user interface elements: buttons, text boxes, menus...)
  - Containers (entities to hold and control the formatting of the components)
  - Events (mouse clicks, mouse movements, key presses, menu item selections...)
- Structure:
  - Define components. There are classes for all these things--JButton, JMenuBar... You create instances of these the way you'd create instances of other classes, e.g.
```
JButton quitButton = new JButton("Quit");
      
```
  - Place components in containers. There are classes for these too--JFrame... You create them in the usual way, and then typically add() components to them, e.g.
```
JFrame theFrame = new JFrame("This is my window");
theFrame.getContentPane().add(quitButton);
      
```
    (From what I've said, you'd get the impression that components and containers are entirely distinct kinds of animals, but in fact the class hierarchy is pretty tangled in this area--e.g. javax.swing.JComponent derives from java.awt.Container... which derives from java.awt.Component)
  - Attach event handlers to components
    - Different components understand different kinds of events (e.g. buttons understand "action" events)
    - You write handlers for the events relevant to your application. This amounts to creating objects that implement an interface--e.g. handlers for "action" events implement the ActionListener interface, which mandates an actionPerformed() method with the following signature:
```
public void actionPerformed(ActionEvent e);
        
```
    - Register your handler by calling addEventTypeListener() on your component, passing a reference to the handler--e.g. to create a handler (which just forces the program to exit) in the style of an anonymous inner class and register it with the button defined above, we could do something like this
```
quitButton.addActionListener(new ActionListener() {
  public void actionPerformed(ActionEvent e) {
    System.exit(0);
  }
});
// alternatively, with a named inner class:
// class myActionListener implements ActionListener {
//   public void actionPerformed(ActionEvent e) { System.exit(0); }
// }
// myActionListener mal = new myActionListener();
// quitButton.addActionListener(mal);
        
```
    - Observe that "the event" is available to your handler as an object (in just the same way that, in the case of a program error, "the exception" is available to your code as an object)--it has methods you can call to determine specific event properties (e.g. precise mouse location).
- Operation: your program starts, as usual, in main(); do the necessary initialization of your user interface components and event handlers; now events start happening: for each one, "the system" (i.e., the Java runtime environment) determines which component is affected, checks whether the component has a listener registered for the event type in question, and if it does, executes that code.

Example: all talk no action. To start off with, here's a program that defines (and displays) user interface elements--a menu, as it happens--but that doesn't know how to do anything, doesn't even know how to shut itself down.

// NoBehavior.java

// need to import the swing package so we can access JFrame etc.
import javax.swing.*;

// subclass JFrame, a fundamental Swing container class
public class NoBehavior extends JFrame {
  public NoBehavior() {
    // call the constructor in the superclass
    super("I am a frame");
    // we want to display a menu; there are three components we have to contend with
    // here: menubar (of which a container can only have one at a time), menu (of which
    // a menubar can have several), menu item (of which a menu can have several); so
    // we make instances of the JMenuBar, JMenu, and JMenuItem classes, and then add
    // the menu item to the menu, add the menu to the menubar, and point the container
    // at its menubar
    JMenuBar myMenuBar = new JMenuBar();
    JMenu fileMenu = new JMenu("File");
    JMenuItem quitItem = new JMenuItem("Quit");
    fileMenu.add(quitItem);
    myMenuBar.add(fileMenu);
    setJMenuBar(myMenuBar);
    // a couple final details to take care of: we say how large the JFrame should be,
    // and also that we want it to display
    setSize(300, 200);
    setVisible(true);
  }
  public static void main(String[] args) {
    NoBehavior nb = new NoBehavior();
  }
}

Example: adding behavior. The last example defined a "Quit" menu item, but didn't say what to do when the item was selected. Here's how we begin to build in behavior:

// Behavior.java

import javax.swing.*;
// now that we're going to be doing some event-handling, we need to import
// java.awt.event
import java.awt.event.*;

// basic structure remains unchanged from the previous example: the class extends
// JFrame; in main() we just make an instance of the class, so all the fun happens
// in the constructor
public class Behavior extends JFrame {
  public Behavior() {
    super("I am a frame");
    // this is a shortcut, introduced in Java 1.3, that lets a program understand
    // window close events; in the good old days you had to add a WindowListener
    // by hand, using the same kind of syntax we have below for the menu item
    setDefaultCloseOperation(EXIT_ON_CLOSE);
    JMenuBar myMenuBar = new JMenuBar();
    JMenu fileMenu = new JMenu("File");
    JMenuItem quitItem = new JMenuItem("Quit");
    // ok, the menu structure is all set up, so now we have to say what to do when
    // the "Quit" item is chosen; a menu item gets an ActionEvent when it's
    // selected, so we have to create an object implementing the ActionListener
    // interface, and pass it to the addActionListener() method of the menu item;
    // as in my example in the initial discussion of event-handling above, the
    // object is an instance of an "anonymous inner class", and all its
    // actionPerformed() method says to do is exit the program immediately
    quitItem.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent e) {
        System.exit(0);
      }
    });
    fileMenu.add(quitItem);
    myMenuBar.add(fileMenu);
    setJMenuBar(myMenuBar);
    setSize(300, 200);
    setVisible(true);
  }
  public static void main(String[] args) {
    Behavior b = new Behavior();
  }
}

Here's a final simple Swing example that exemplifies the handling of some other components and event types. The idea here is simply to display a container that has a button and some text fields. The button is set up to trap mouse-motion events, and we use the text fields to display some event particulars (mouse coordinates and time of the event)

// MouseReader.java

import javax.swing.*;
// needed for FlowLayout etc.
import java.awt.*;
import java.awt.event.*;
// needed for Date
import java.util.*;

// same basic structure as previously: a JFrame-extending class, all the action
// in the constructor
public class MouseReader extends JFrame {
  JButton button;
  JTextField tX, tY, tDate;
  public MouseReader() {
    super("I am a frame");
    setDefaultCloseOperation(EXIT_ON_CLOSE);
    // to manipulate the JFrame the way we want to here, we're going to need
    // (unlike the case of tacking on a menu bar) a reference to its "content
    // pane"
    Container c = getContentPane();
    // the arrangement of components in a container is governed by its
    // "layout"; here we say we'd like a "flow" layout, which orders
    // components from left to right, row by row
    c.setLayout(new FlowLayout());
    // make instances of the components
    tX = new JTextField(5);
    tY = new JTextField(5);
    tDate = new JTextField(20);
    button = new JButton("The Button");
    // add a listener to the button to listen for mouse motion events;
    // the MouseMotionListener interface mandates mouseDragged() and
    // mouseMoved() methods, the former of which we just ignore;
    // mouseMoved() fetches the mouse's x and y coordinates and the
    // event time from the event object, and writes them into the text
    // fields, using the setText() method of JTextField
    button.addMouseMotionListener(new MouseMotionListener() {
      public void mouseDragged(MouseEvent e) { }
      public void mouseMoved(MouseEvent e) {
        // call getX() on "the event" to get the mouse's x coordinate
        // (as an int); setText() wants a String parameter, so we turn the
        // int into an Integer, and call Integer's toString()
        tX.setText((new Integer(e.getX())).toString());
        tY.setText((new Integer(e.getY())).toString());
        Date d = new Date(e.getWhen());
        tDate.setText(d.toString());
      }
    });
    // add the button and text fields to the container
    c.add(tX);
    c.add(tY);
    c.add(button);
    c.add(tDate);
    setSize(300, 200);
    setVisible(true);
  }
  public static void main(String[] args) {
    MouseReader b = new MouseReader();
  }
}

2. Threads

Multitasking operating systems create the illusion of running multiple processes simultaneously by executing those processes in a sequence of small time slices. "Threading" extends this idea to single programs: you divide your program into multiple "threads of control", and these execute independently and "simultaneously" (i.e., each gets its own time slice).
The motivations for threading are many: a primary one is to guarantee that distinct modules in your program get a fair share of CPU time (e.g. in an interactive program you'd like the user interface code to have a chance to run even while the program's doing something CPU intensive or I/O-bound.
Java threads are (what else?) objects. They're objects that either derive from the Thread class or implement the Runnable interface, which stipulates that you have a method whose signature is:
```
public void run();
  
```
In either case, you write a version of run() that contains all you want your thread to do. You start the thread by calling its start() method (inherited from Thread), which does some behind the scenes work to call your run() (this is strange, but no stranger than execution magically beginning at the start of main() in a regular Java application); and the thread then executes 'til run() terminates.

Here's an example that's adapted from one that comes up early in Eckel's chapter on threads (see especially pp. 831-833). We're going to have a program that displays a couple of buttons and a text field in a JFrame. The text field displays an incrementing counter (this is supposed to be the part of the program that wants to hog the whole CPU). The buttons supposed let the user start and pause the counter (this is supposed to be the interactive part of the program, the part we're reserving some CPU cycles for by implementing threading). Eckel's version runs as both an applet and a standard application. I've cut out the applet part and made a couple other syntactic changes

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;

// overall structure similar to previous examples: our main class extends
// JFrame; main() just makes an instance of the class, all the work's in the
// constructor
public class Counter extends JFrame {

  // this is going to be our separate thread for handling the incrementing
  // counter
  private SeparateSubTask sp = null;
  // text field and buttons
  private JTextField t = new JTextField(10);
  private JButton
    start = new JButton("Start"),
    onOff = new JButton("Toggle");

  // constructor; the operations here follow the same general lines as the
  // earlier Swing examples
  public Counter() {
    // set up for window closing
    setDefaultCloseOperation(EXIT_ON_CLOSE);
    // get the content pane of the JFrame and set the layout
    Container cp = getContentPane();
    cp.setLayout(new FlowLayout());
    // add the text field to the JFrame
    cp.add(t);
    // add an ActionListener to the start button that creates an
    // instance of our Thread class (if we haven't already done this)
    start.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent e) {
        if (sp == null) sp = new SeparateSubTask();
      }
    });
    // add the start button to the JFrame
    cp.add(start);
    // add an ActionListener to the toggle button that calls a method that
    // just toggles a boolean variable
    onOff.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent e) {
        if (sp != null) sp.invertFlag();
      }
    });
    // add the toggle button to the JFrame
    cp.add(onOff);
    setSize(300, 100);
    setVisible(true);
  }

  // here's the class definition for the thread
  class SeparateSubTask extends Thread {
    // state of the counter
    private int count = 0;
    // are we running or paused?
    private boolean runFlag = true;
    // constructor for the thread; it just calls start() on itself (i.e.,
    // when a thread object of this kind is created, it starts running
    // automatically
    SeparateSubTask() { start(); }
    void invertFlag() { runFlag = !runFlag; }
    public void run() {
      // run() runs forever
      while (true) {
        // sleep() is a Thread method that'll make the thread it's called
        // on unrunnable for the specified number of milliseconds; sleep()
        // can throw an exception, so we wrap the call in a try-catch
        try { sleep(100); }
        catch (InterruptedException e) { System.out.println("Oops"); }
        // (depending on whether we're paused or running), increment the
        // counter and write its value into the text field
        if (runFlag)
          t.setText(Integer.toString(count++));
      }
    }
  }

  public static void main(String[] args) {
    Counter c = new Counter();
  }
}

Thread programming brings with it some complications, and a principle one has to do with access to common resources. In a program with a single instruction sequence you know (in principle) who's doing what to whom and in what order, but this is no longer the case with threads: it's the Java scheduler that decides when threads run, so the programmer no longer directly controls the sequence in which the program executes. This has immediate consequences for programs in which multiple threads access shared objects. Consider the following case--we have a class containing a static variable (yet another counter) and a method that increments the counter (we'll do this a couple different ways and see if we can cause some trouble); the constructor for the class makes a number of (internally defined) threads and start()s them. All each thread does is to call the incrementing routine and then print who it is and the current (i.e., post-incremented) state of the counter.
If incrementCounter() is defined in a reasonably economical way, the results of the program will probably look entirely natural: Thread 0 says the counter is 1, Thread 1 says the counter is 2... Thread 24 says the counter is 25. Throw some sand in the works (e.g. with a very long for-loop) and the results start to look odd... and variable from run to run. The difficulty is that there's no guarantee that incrementCounter will run to completion--a thread can have its time slice expire after it's grabbed the counter but before it's updated it. This means the next thread may grab the old counter value and... we're out of sync.

Of course no one throws sand in their program just for fun, but the example illustrates a general problem: if we have multiple threads accessing shared resources, there's a chance that some threads will end up with invalid views of those resources... because the resources have been changed by other threads. What we need is something to make operations like incrementCounter() atomic, indivisible in the sense that one thread having started to execute it, another can't begin 'til the first has finished. Java provides this kind of indivisibility by way of the synchronized keyword: if an object has a synchronized method, only one caller at a time can execute that method.

// as currently commented, this program will probably produce reasonable-looking
// results; uncomment the for-loop in incrementCounter() and all hell breaks
// loose; switch to the "synchronized" signature for incrementCounter() and order
// is restored
public class ThreadTest {

  private static int counter = 0;

  // constructor; make some threads and start them
  public ThreadTest() {
    final int numThreads = 25;
    for (int i = 0; i < numThreads; i++)
      (new InternalThread(i)).start();
  }
//  public synchronized void incrementCounter() {
  public void incrementCounter() {
    int tmp = counter;

// throw some sand in there (and hope for thread pre-emption); there are other
// ways to do this: one would be to put the thread to sleep()
//    for (int i = 0; i < 10000000; i++) ;
    tmp = tmp + 1;
    counter = tmp;
  }

// er, getCounter() causes additional complications--incrementCounter and
// getCounter() together aren't atomic, so it'd really be better to
// get rid of this
  public int getCounter() { return counter; }

  // the thread class; 'threadNum' is just for identification purposes in the
  // print statement
  class InternalThread extends Thread {
    private int threadNum;
    public InternalThread(int k) { threadNum = k; }
    // a nice simple run(): call incrementCounter() in the enclosing object,
    // and then print some stuff
    public void run() {
      incrementCounter();
      System.out.println("Thread " + threadNum + ": " + getCounter());
    }
  }

  public static void main(String[] argv) {
    ThreadTest t = new ThreadTest();
  }
}

3. "Reflection"

We've seen that the "instanceof" operator lets you query whether an object "is-a" member of a given class. Java also provides a way of directly determining the immediate class to which an object belongs (and then of discovering various characteristics of that class).
You can call getClass() on any object--i.e., getClass() is defined in java.lang.Object--to ascertain its immediate class. Or more exactly, calling getClass() on an object returns an instance of the class Class (namely the instance representing the immediate class of the object in question). Yes, there really is a class called Class whose instances are representations of the classes Java knows about. And as it turns out there are other ways of producing Class objects besides getClass(): for example, there's a static method in Class called forName() that takes as a parameter a String representation of a class name and returns the corresponding Class object
Given a Class object, you can determine its properties via methods in Class--determine whether it's a regular class or an interface, determine the base class from which it derives, determine its constructors, data members and methods (e.g. getMethods() returns an array of Method objects representing the methods of the class).

Here's an example of the practical use of these facilities, adapted from some of the sample files accompanying the Apache Foundation's Xerces XML parser. We have a small demo program that counts the number of elements in an XML document. It relies on an XML parser to turn the text representation of the document into a logical, tree-oriented representation. Which parser should it use? Well, the demo accompanies Xerces, so naturally it uses Xerces by default, but wouldn't it be nice--nicer--if the user had the option of specifying a parser on the command line?:

// lots and lots of stuff snipped to save space
package dom;
public class Counter {
  // here's the name of the parser we'll use by default
  protected static final String DEFAULT_PARSER_NAME = "dom.wrappers.Xerces";
  public static void main(String argv[]) {
    ParserWrapper parser = null;
    // deal with command line args
    for (int i = 0; i < argv.length; i++) {
      String arg = argv[i];
      if (arg.startsWith("-") { // we want options to start with a hyphen
        String option = arg.substring(1);
        if (option.equals("p")) { // is this the p-is-for-parser option?
          String parserName = argv[++i];
          try {
            // Here's the fun part. The program only learns the name of the
            // class the user wants to user for the parser now, at runtime.
            // Call Class.forName() on the string we get from the command line
            // to get a Class object; call newInstance() on that object to
            // make a new object of that class; cast to something convenient
            parser = (ParserWrapper)Class.forName(parserName).newInstance();
          }
          catch (Exception e) { System.out.println("Oops"); }
        }
        // do other options
      }
    }
    if (parser == null) {
      try {
        parser = (ParserWrapper)Class.forName(DEFAULT_PARSER_NAME).newInstance();
      }
      catch (Exception e) { System.out.println("Oops"); }
    }
    // now we've got our parser, proceed with the program

IPL-Java Home | IPL-Java Wiki