Due: 10:00 A.M., Monday, 11/03/08

For this assignment, you are to augment Program 7 so that it implements some file I/O commands.

This program should still follow the structure of Program 5: it should have classes TestCheckers, Game, Checkers, and Board that satisfy the design requirements (class structure, methods, and packaging) specified in Program 5.

As in Program 7, the main() should accept commands from the command line, one command per line. The commands that need to be modified or added are:

1. start
   There are three cases:
   (1) No game is in progress. In this case, a new game begins, with the pieces placed as they should be at the start of a game.
   (2) A game is already in progress, but it has not yet been saved to a file.
   The user is asked if the game should be saved.
   If the user responds yes, then the user is prompted for a filename.
   If the filename already exists, then the user is asked whether the file should be overwritten. If the user responds yes then the game is written to that file.
   If the file does not exist, then it is created and the game is written to that file.
   Then a new game begins, with the pieces placed as they should be at the start of a game.
   (3) A game is already in progress, and it has previously been saved to a file, either during this run of the program or some previous run.
   The user is asked if the game should be saved. If the user responds yes then the game is written to that file.
   Then a new game begins, with the pieces placed as they should be at the start of a game.
   
2. resume [filename]
   Three cases:
   (1) No game is in progress. Then the game that was saved in [filename] is read in, and it is resumed. (If no filename was specified, then the user is prompted for it.)
   (2) A game is already in progress, but it has not yet been saved to a file.
   The user is asked if the game should be saved.
   If the user responds yes, then the user is prompted for a filename.
   If the filename already exists, then the user is asked whether the file should be overwritten. If the user responds yes then the game is written to that file.
   If the file does not exist, then it is created and the game is written to that file.
   Then the game that was saved in [filename] is read in, and it is resumed. (If no filename was specified, then the user is prompted for it.)
   (3) A game is already in progress, and it has previously been saved to a file, either during this run of the program or some previous run.
   The user is asked if the game should be saved. If the user responds yes then the game is written to that file.
   Then the game that was saved in [filename] is read in, and it is resumed. (If no filename was specified, then the user is prompted for it.)
   
3. save [filename]
   Three cases:
   (1) No game is in progress. This is an error.
   (2) A game is already in progress, but it has not yet been saved to a file.
   If [filename] is not specified, then the user is prompted for a filename.
   If [filename] does not exist, then it is created, and the game is written to that file.
   If [filename] already exists, then the user is asked whether the file should be overwritten. If the user responds yes, then the game is written to that file.
   (3) A game is already in progress and it has previously been saved to a file.
   If [filename] is not specified or it is the same as the file that the game is already saved in, then it is written back to the file.
   If [filename] is specified and it is different from the file that the game is already saved in, and [filename] does not exist, then it is created, and the game is written to that file.
   If [filename] is specified and it is different from the file that the game is already saved in, and [filename] exists then the user is asked whether the file should be overwritten. If the user responds yes then the game is written to that file.
   
4. quit
   If no game is in progress, then the program terminates.
   If a game is in progress, then the user is asked whether the game should be saved. If the response is yes, then the game is saved as in the save command. Then the program terminates.

Your grade will be based on how well you design and implement the code, how thorough your exception handling is, on good programming practices, and on thorough testing. Coding guidelines for Java programs are posted here.

Add comment documentation to your program (all classes) and use javadoc to extract the documentation into an HTML file. Include a javadoc comment for each class and each method. The class comment should include your name and the date (use the @author tag). Method comments should briefly describe the purpose of the method, its arguments, and what, if anything, it returns (using @param and @return as appropriate).

The physical location of the javadoc comments is critical. A class comment must immediately precede the line containing the keyword class, and method comments must immediately precede the method.

When you have commented your source files, run javadoc to create the .html files and view them in a browser of your choice.

• Turn in a hardcopy printout of your java source files TestCheckers.java, Game.java, Board.java, Checkers.java and any other .java files your program uses.

  Do not give me a copy of the javadoc.html files.

• All Java programs will be submitted by copying (or ftping) them to a specially designated directory in AFS. Each person in the class has a subdirectory which has the same name as your login in /afs/cu/class/cs242/fa08

  Within this individual directory, create a subdirectory named p8. Copy only the source files and an executable JAR file into this directory, not class files or javadoc files. So, for example, if your login name was smithjd then the five files TestCheckers.java, Game.java, Board.java, Checkers.java, TestCheckers.jar, and any other .java files your program uses should be copied to /afs/cu/class/cs242/fa08/smithjd/p8. These directories have permissions set so that no one other than yourself and Prof. Lynch can read the files. You may, of course, use whatever operating system and compiler you wish to develop your code, but the version you turn in, both hardcopy and the files submitted to AFS, must compile and run under JDK 5.0 on the Clarkson Windows operating system.

  I should be able to run your program by downloading TestCheckers.jar into any folder and entering the command line

  java -jar TestCheckers.jar

Here is one way to create an executable JAR file.
Assume the file TestCheckers.java contains the method main,
the package Games contains the files Game.java, Checkers.java, Board.java, and any other .java files needed by the program,
and TestCheckers.java imports the package Games.

Then the program can be compiled by
javac -classpath . TestCheckers.java

and executed by
java -cp . TestCheckers

(The classpath options may not be necessary on your computer.) When you are satisfied that the program is correct, you can create an executable JAR file in the following way. First, you must create a manifest file containing the line
Main-Class: TestCheckers

There must be exactly one space after the :, and the line must be terminated with a new line or return. You can name the manifest file whatever you want. Suppose it is named Manifest.txt. Next, you create the JAR file containing the manifest file by
jar cfvm TestCheckers.jar Manifest.txt TestCheckers.class Games/*.class

Then you can execute the JAR file by
java -jar TestCheckers.jar

More information on JAR files may be found in the tutorial Packaging Programs in JAR Files.

---

Your grade on the program will be based on:
• Correct execution. The program must follow all the specifications above.
• Correct implementation. The program must follow all the design requirements above.
• Error checking. You have to figure out what kinds of errors your program should check for, and how it should handle them, within the design constraints.
• Readability of the code: commented and well-structured, so that it is clear what the code is doing. Use an accepted programming style. The style of the text is fine, or you can follow the Code Conventions. Whatever you do, be consistent.
• Appearance of the output. At this point, we haven't covered any of the ways to generate really nice looking output, but the display command should produce a picture of the board with all the rows and columns lined up nicely, and any error messages should be well-formatted and easy to read.
• Timely submission of your program. All hardcopy must be turned in by the deadline. Late programs will not be accepted. Printouts submitted electronically will be ignored.