Teaching AP courses in Java using Macs

Using OS X

However, recently a different problem turned up with OS 10.2.6 and the Java SDK 1.4.1. The "shading" of the fish is where it belongs, but the outline of the fish and its eyes are shifted so that they center at a corner of the square instead of at the center the square. It is also a problem with graphics acceleration, but this version did not allow graphics acceleration to be turned off.

Apple has now fixed this bug and has released an updated version. To get it, run "System Preferences" and select "Software Update". It will give you the option to download a new version of Java SDK 1.4.1. Download it, restart your computer, and the problems with offset fish outlines disappears.

Using OS 9 or earlier

Ideally everyone would be able to update to the latest versions of the operating system and the Java language. It is the easiest and cleanest way to deal with this problem. However, for those who cannot upgrade, there is a way to work around the problem.

There are two areas which will cause difficulty. The first is that a number of the library classes and interfaces in the AP Java subset were not in SDK 1.1. These classes are:

• java.util.Random
• java.util.ArrayList
• java.lang.Comparable
• java.util.List
• java.util.LinkedList
• java.util.Set
• java.util.HashSet
• java.util.TreeSet
• java.util.Map
• java.util.HashMap
• java.util.TreeMap
• java.util.Iterator
• java.util.ListIterator

Fortunately Sun has provided two Java Archives, collections.jar and swingall.jar, that implement all of the library classes needed to teach an AP course and the Swing library. You can download these two .jar files by clicking on the following link:

• JarFiles.zip

To use these .jar files, put them in the same folder with the code to be run or add them to a library folder and make sure that the class path or the access path in the IDE that you are using includes that libarary folder.

IMPORTANT: If you are using CodeWarrior, you can save yourself a lot of problems by putting a copy of collections.jar in the following folder, where the arrows show the sequence of folders to follow, starting with the System Folder:

   System Folder --> Extensions --> MRJ Libraries --> MRJClasses 

The Swing classes can be imported by using the statement:

    import javax.swing.CLASSNAME;

    import java.util.CLASSNAME;

    import java.lang.Comparable;

    import com.sun.java.util.collections.CLASSNAME;

This means that code that is taken from books or other sources that use any of the classes and interfaces named above must have its import statements modified. This is unfortunate, but given the protection rules in Java there was no good way around it. Only the builtin Java libraries can have classes whose path name begins "java.". Therefore the people at Sun had to create a different name for their "add-on" collections library. You will need to modify all import statements that involve the classes listed above.

Unfortunately, the Marine Biology Simulation case study uses graphics classes (in particular ones in the Graphics2D library) that are not available in SDK 1.1. To get around this problem I have re-written the GUI interface to use only older graphics classes. The GUI interface is not as nice as the one in the standard MBS release, because methods for creating gradient shading and other nice effects are not in the earlier graphics package. However, it works on machines and browsers that have only implemented SDK 1.1.

To download this version of the MBS case study as a .zip file, click on the following link:

• JavaMBS1pt1.zip

This file, when unzipped, contains all the code needed to run the MBS case study. However, if you are curious about the "black-box" and GUI code or wish to to modify yourself, it is available here:

• Code.zip

Using Textbook Programs with swingall.jar

The Sun documentation on Java (available at http://java.sun.com/j2se/) gives the version of the SDK in which a class, method, or constant was introduced. If a program that you get from a book uses a feature introduced in 1.3 or later, you will have to re-write the code to use equivalent features from an earlier version.

One particular problem arises frequently enough to make it worth describing here. It involves the JFrame constant EXIT_ON_CLOSE. This constant does not appear in swingall.jar, so code that uses it gives an "undefined variable" error message. The simple, if somewhat kludgy way, to fix this problem when using swingall.jar is to replace the EXIT_ON_CLOSE constant by 3 everywhere it appears.

The following explanation of the problem and why replacing EXIT_ON_CLOSE by 3 works is condensed from Cay Horstman's book Core Java, pp. 301-302.

The EXIT_ON_CLOSE parameter for the setDefaultCloseOperation method was introduced with version 1.3 of the Java 2 SDK. If you are using an earlier version, you need to remove this line from the source code....

Of course, after removing the call to setDefaultCloseOperation, the program won't exit when you close the window. To exit the program, you need to kill it....

Alternately, you can replace the call to setDefaultCloseOperation method with the following code:

   frame.addWindowListener(new
      WindowAdapter()
      {
         public void windowClosing(WindowEvent e)
         {
            System.exit(0);
         }
      });

The preceding note told you the "official" way of making a frame close on exit in a pre-1.3 version of the Java 2 SDK. However, in some of those versions, the call:

   frame.setDefaultCloseOperation(3);