Let's start out by looking at how you translate, compile, and run your SQLJ program. Make sure that it lives in a file with the extension *.sqlj (instead of *.java). Then translate and compile your files in one step.

sqlj MyFile.sqlj MyOtherFile.sqlj MyJavaFile.java

Yes, this even compiles your Java files in the same fell swoop. This should —if everything goes all right— create *.class files (and some *.ser files), and you can then issue

java MyFile

provided, of course, that MyFile has a method

public static void main(String[] args) { ... }

Even though you are familiar with .class files —the result of Java compilation— you will be curious about these .ser files that the SQLJ translator produces. We also call them (serialized) profiles. They are serialized Java objects that contain all the information about the static SQL statements in your .sqlj source files, such as the SQL code, the types and names of the host variables that occur in the SQL statement, and what kind of SQL statement this is (a commit/rollback, a query, a DML statement, and so on).

• Make sure that all the Java classes referenced by your program are either passed as a .sqlj or .java source file on the SQLJ command line or can be accessed through your CLASSPATH.
• When you invoke sqlj, a number of things go on "under the covers". To get the full story, see SQLJ Developer's Guide and Reference, Chapter 1, Section "Basic Translation Steps and Runtime Processing", and Chapter 9, Section "Internal Translator Options".
• To learn more about profiles, see SQLJ Developer's Guide and Reference, Chapter 10, Section "More About Profiles".

1. (**) What problem arises (and under what circumstances) when the preceding Warning is not followed? What difference in behavior do you notice when you give the option -checksource=false (Note: This option sets the same behavior that SQLJ version 8.1.5 has.)