ObjectStore Java Tutorial
Chapter 4

Compiling and Running an ObjectStore Program

To run an application, such as the Personalization application, you must perform the steps described in the following sections:

Installing ObjectStore

Adding Entries to Your CLASSPATH

Compiling the Program

Running the Postprocessor

Running the Program

Installing ObjectStore

For information about installation, see the README.htm file in the top-level directory of your ObjectStore installation.

After the installation is complete, update your PATH environment variable to contain the bin directory from the distribution. This allows you to use the Class File Postprocessor (osjcfp) and other tools.

For example, under Windows NT you would add the following entry to your PATH environment variable:

c:\Odi\osji\bin

Adding Entries to Your CLASSPATH

ObjectStore requires certain entries in the CLASSPATH environment variable so that you can use ObjectStore. When you want to develop ObjectStore programs as well as use ObjectStore, you must add additional entries to your CLASSPATH.

Entries Required to Run ObjectStore Applications

To use ObjectStore, you must set your CLASSPATH environment variable to contain

You must have these zip files explicitly listed in your class path. You cannot list only an entry for the directory that contains them. For example, under Windows NT, you might have the following entries in your CLASSPATH variable:

c:\Odi\osji\osji.zip;c:\Odi\osji\tools.zip

Entries Required to Develop ObjectStore Applications

To develop and run ObjectStore applications, you must add entries to the CLASSPATH variable that allow Java and ObjectStore to find your

The source directory contains your Java source files and your class files (compiled source). ObjectStore must postprocess the class files for your persistence-capable and persistence-aware classes. ObjectStore takes these .class files and produces new .class files that contain annotations that are required for persistence.

You decide whether to place the annotated files in the same directory as the source files or in a separate directory.

For example, suppose c:\Odi\osji\COM\odi\tutorial is the directory that contains the source files for the tutorial package. You decide to annotate in place. That is, you plan to instruct the postprocessor to overwrite the original class files with the annotated class files. In this case, you must add the following entry to your CLASSPATH variable:

c:\Odi\osji
This entry allows the Java VM and ObjectStore to find the COM\odi\tutorial directory, which contains both the source files and the annotated class files.

Suppose you decide to place the annotated class files in a separate directory from the source files, for example, c:\Odi\osji\COM\odi\tutorial\osjcfpout. In this case, you must add the following entries to your CLASSPATH variable:

c:\Odi\osji\COM\odi\tutorial\osjcfpout;c:\Odi\osji
The first entry allows ObjectStore to find the annotated class files. The second entry allows ObjectStore to find the source files.

Background About Different Kinds of Class Files

In general, when you are developing an ObjectStore application, you are concerned about three kinds of .class files:

After compiling your application, ObjectStore has to find the original class files to annotate them. The postprocessor gives you the option of annotating the class files in place, which means that the superseded class files are replaced by the annotated class files. This is generally the easiest way to use ObjectStore, since your CLASSPATH does not have to contain a separate entry for the annotated class files.

After postprocessing your application, you can run your application. When you run your program, Java has to locate the annotated class files and the unannotated class files that have not been superseded. The location of the annotated class files must precede the location of the original class files in your CLASSPATH. This allows the Java VM to find the annotated class files before it finds the superseded (original) class files. You can find detailed instructions for doing this in ObjectStore Java API User Guide, Automatically Generating Persistence-Capable Classes.

Compiling the Program

You compile a ObjectStore application the same way you compile any other Java application. For example, to compile the Personalization application, change to the c:\Odi\osji\COM\odi\tutorial directory and enter

javac *.java
You can use the asterisk to compile all .java files or you can compile each file individually by specifying the file name. Case is significant for the file name, so you must specify, for example, User.java and not user.java.

When you compile the Personalization application, the javac compiler outputs the following run-time byte code files:

Running the Postprocessor

You must run the class file postprocessor on the class files of the classes that you want to be persistence-capable. The postprocessor generates new annotated files in place (overwrites original class files) or in a directory that you specify. To run your program, you use the annotated class files and not the original class files.

Before you run the postprocessor, ensure that the bin directory that contains the postprocessor executable is in your path, as noted in Adding Entries to Your CLASSPATH.

Complete information about the postprocessor is in ObjectStore Java API User Guide, Chapter 8, Automatically Generating Persistence-Capable Classes.

Example of Postprocessing Classes in Place

In the Personalization application, both the Interest and User classes are persistence-capable. To postprocess these classes in place, change to the c:\Odi\osji\COM\odi\tutorial directory and enter

osjcfp -inplace -dest . Interest.class User.class
When you specify the -inplace option, the postprocessor ignores the destination argument (-dest), but it is still required.

Specifying an Input File to the Postprocessor

If you have several class files to postprocess, you might find it easier to use a file to specify the arguments. To do this, create a text file that contains the arguments for the postprocessor and specify the text file name with the @ sign when you run the postprocessor.

For example, suppose that in the c:\Odi\osji\COM\odi\tutorial directory you create the cfpargs file with these contents:

-inplace -dest .
-pc User.class Interest.class
The -pc option instructs the postprocessor to make the specified classes persistence-capable. You can then run the postprocessor with this command:

osjcfp @cfpargs

Placing the Annotated Files in a Separate Directory

To put the annotated files in a separate directory, specify the -dest option followed by the name of the directory in which you want the postprocessor to put the annotated class files. For example, you can enter the following command to place the annotated User and Interest class files in the osjcfpout directory:

osjcfp -dest osjcfpout Interest.class User.class
The -dest option specifies the destination directory for the annotated files. The argument for this option must be the same as the directory in your CLASSPATH environment variable that establishes the location of the annotated files.

In the Personalization application, this is c:\Odi\osji\COM\odi\tutorial\osjcfpout. You must explicitly create this directory before you run the postprocessor.

Description of Output from the Postprocessor

When you run the postprocessor to make a class persistence-capable, the postprocessor outputs two class files for each class it postprocesses. One class is the annotated class file and the other class contains information that ObjectStore uses to store instances of that class.

For example, the osjcfp command that places the annotated class files in the osjcfpout directory outputs these annotated class files:

The postprocessor creates a directory structure that matches your package structure.

Additional Information About the Postprocessor

Under normal circumstances, you must postprocess together all classes in your application that you want to be persistence-capable or persistence-aware. Failure to do so can result in problems that are difficult to diagnose when you run your application. For example, objects might not be automatically fetched from the database when needed.

The postprocessor must be able to examine all class files in an application when it makes any class in the application persistence-capable. There are postprocessor options that allow you to determine which classes the postprocessor makes persistence-capable. If it is inconvenient or impossible to postprocess together all classes in your application, you can postprocess separate batches of files. See ObjectStore Java API User Guide, Chapter 8, Postprocessing a Batch of Files Is Important.

It is good practice to provide accessor methods to encapsulate state in an object, as shown in the source code for the Interest class in Appendix A, Source Code. When using ObjectStore, accessor methods allow ObjectStore to automatically fetch objects from the database. It is easy to localize where ObjectStore must annotate code to perform fetch and update checks, which occur only in the accessor methods as opposed to being spread throughout your code.

Running the Program

Before you run a ObjectStore program, ensure that the ObjectStore lib directory is in your library search path. Run your ObjectStore program as a Java application.

For example, here is a typical command line that runs the Personalization application:

java COM.odi.tutorial.TestDriver test.odb
When you run an ObjectStore program, you specify the fully qualified class name to the Java VM. In this example, COM.odi.tutorial.TestDriver is the fully qualified class name.

The TestDriver program expects an argument that contains the pathname of the database's .odb file, namely test.odb. The application also creates test.odt and test.odf, and these three files (the .odb, .odt, and .odf files) form the database. You can specify any pathname you want, as long as the file name ends with .odb. This example uses a relative pathname, so ObjectStore creates the files in the directory in which you run the program.

Sample Output from the application is in Appendix B.



[previous] [next]

Copyright © 1998 Object Design, Inc. All rights reserved.

Updated: 10/07/98 07:05:53