COMP 212 Lab 2: Javadoc, Packages, Factory Pattern

This tutorial covers:


Java Documentation Style

The Java Development Kit (JDK) includes a tool called Javadoc which generates documentation for Java source code with comments written in accordance with the Java documentation style. Take a quick look at the following links to see more examples.

Copy this tutorial directory (~comp212/public_html/01-spring/labs/02/) into your own directory. It includes Java source code for a version of lists. Use Emacs to look at both the code and the comments, which follow the Javadoc conventions.

Exercises

  1. Run the Javadoc utility on this code using

         javadoc *.java
         
    Browse the generated HTML files using Netscape's File menu option Open Page. Does the documentation include descriptions of the private fields and methods?

    Now execute the command:

         javadoc -private *.java
         
    What's the difference?

  2. Now try simply

         javadoc
         
    Like many UNIX commands, running the program without specifying anyoptions will provide a brief description of its possible usage. Take a brief look at the explanation of the flags. In particular, note the -d flag for putting the documentation into a separate directory.


Packages

A Java package is a grouping of classes similar to the notion of a directory is a grouping of files. Packages are used to help avoid name clashes and to hide particular pieces of code from the clients. A package has a name, such as utility or java.lang.util. In general, a package name is a series of strings of alphanumeric characters (starting with an alphabetic character) and separated by periods. To make a java class part of a particular package, say list, you must add the declaration package list; to the very top of the class source file.

Also, you will need to put the file in the directory structure that mirrors the package name. For example, the java classes that belong to the package list should be in a directory also named list. If you don't do this, it will still compile, but it won't run correctly.

Exercises:

  1. Add the package list; declaration to the top of AList.java. You need to create a subdirectory called list and move AList.java into it.

    Now compile using

         javac list/AList.java
         
    Note that you should always compile from your project's main directory. If you compile from within a package subdirectory, it doesn't find all the supporting definitions.

    We can't run anything yet, because that's just a piece of the whole program.

  2. Add the package list; declaration to the top of EmptyList.java and NEList.java, and move them into the list subdirectory. Do not make ListClient.java part of the package. ListClient.java does not have a package name, and it thus said to be in the no-name (or default) package.

    Also, remove the public access from the EmptyList and NEList classes. By default, a class is "package-private", i.e., it is known within the package, but not from outside. If you try to compile ListClient.java now, you will get an error message. Try it to see what happens.

    You need to add the statement import list.*; to the top of ListClient.java to indicate to the compiler that you are using all the public classes in that package. Try to compile it again.

    You should see a few error messages saying that you can't use EmptyList.java and NEList.java because these classes are not public. This is because the ListClient class is not part of the list package. One way to resolve this problem by making ListClient part of the list package. A class of a package can access all the classes (public or "package-private") in the package. However this is not a good solution in general because a client may be using many classes from different packages, but not class can be part of more than one package. A better solution is to use a "factory".


Factories

Good software engineering practices advocate the principle of "information hiding": all implementation details should be hidden from client code. In the case of our lists, EmptyList.java and NEList.java are the details that clients should not know about. The client should only program to the AList abstraction. For this reason EmptyList.java and NEList.java are not public classes. But the client needs to have a way to create concrete instances of EmptyList and NEList somehow.

A solution is to add a public "factory" class that is part of the list package, which knows how to call the list constructors to manufacture these classes. Such a class follows the "factory design pattern".

Exercises: