Release 2 (9.2)
Part Number A96655-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i SQLJ Developer's Guide and Reference Release 2 (9.2) Part Number A96655-01 |
|
Once you have written your source code, you must translate it using the SQLJ translator. This chapter discusses the SQLJ translator command line, options, and properties files.
The following topics are discussed:
This section discusses general command-line syntax for the script sqlj that you use to run the SQLJ translator, and lists all the options available. It then discusses SQLJ properties files, which you can use instead of the command line to set most options, and the SQLJ_OPTIONS environment variable, which you can use in addition to or instead of the command line for setting options.
For detailed information about settings for basic options, see "Basic Translator Options".
For information about more advanced options, see "Advanced Translator Options" and "Translator Support and Options for Alternative Environments".
The sqlj script invokes a Java virtual machine (JVM) and passes the class name of the SQLJ translator (sqlj.tools.Sqlj) to the JVM. The JVM invokes the translator and performs operations such as parsing the command line and properties files. For simplicity, running the script is referred to as "running SQLJ", and its command line is referred to as the "SQLJ command line".
This is the typical general syntax for the command line:
sqlj <optionlist> filelist
The option list is a list of SQLJ option settings, separated by spaces. There are also prefixes to mark options to pass to the Java interpreter, compiler, and customizer (if applicable).
The file list is the list of files, delimited by spaces, to be processed by the SQLJ translator. The files can be .sqlj, .java, .ser, or .jar files, as explained in "Command-Line Syntax and Operations". The * wildcard entry can be used in file names. For example, Foo*.sqlj would find Foo1.sqlj, Foo2.sqlj, and Foobar.sqlj.
Do not include .class files in the file list, but do be sure that your classpath is set so that the SQLJ translator can find any classes it must have for type resolution of variables in your SQLJ source files.
If the -checksource flag is enabled (its default setting), the SQLJ translator can also find classes it needs in uncompiled .java files in the classpath. See "Source Check for Type Resolution (-checksource)".
|
Notes:
|
This section discusses options supported by the SQLJ translator. Boolean options are referred to as flags. Also listed are prefixes, used to pass options to the JVM, which the SQLJ script invokes, and to the Java compiler and SQLJ profile customizer, which the JVM invokes.
Table 8-1 below lists options supported by the SQLJ translator, categorized as follows:
javac options that SQLJ recognizes directly, without the compiler prefix. They are passed to the Java compiler, typically javac, and some also affect SQLJ translator settings. These options are discussed in "Option Support for javac".loadjava utility.SQLJ_OPTIONS environment variable can be used in addition to, or instead of, the command line for setting options. See "SQLJ_OPTIONS Environment Variable for Option Settings".true or false, but they can also be enabled/disabled by setting them to yes/no, on/off, or 1/0.For discussion and an example of command-line syntax and operations, see "Command-Line Syntax and Operations".
For compatibility with the loadjava utility used to load Java and SQLJ applications into Oracle9i, the following alternative syntax is recognized for the indicated options when specified on the command line. (This is also noted in Table 8-1 above.)
-e (for -encoding)-h (for -help)-p (for -password)-u (for -user)-v (for verbose message output; equivalent to -status)To maintain full consistency with loadjava syntax, you can use a space instead of "=" in setting these options, as in the following example:
-u scott/tiger -v -e SJIS
For general information about the loadjava utility, see the Oracle9i Java Developer's Guide.
|
Note: This alternative option syntax is recognized only on the command line or in the |
SQLJ supports option settings for javac--the Java compiler supplied with the Sun Microsystems JDK--in several ways:
javac options that take values are combined into SQLJ options (-classpath, -d, -encoding).javac options that take values, special processing has been implemented to correctly pass the value to the compiler (-bootclasspath, -extdirs, -target). These require a compiler prefix. They have no effect on SQLJ operation.javac are recognized on the command line without a compiler prefix (-depend, -deprecation, -g, -nowarn, -O, -verbose). Some of these flags affect SQLJ translator flag settings as well.This is summarized in Table 8-2. All of these options can be set in the SQLJ command line or in a properties file, though sometimes a compiler prefix is required, as noted in the table.
Refer to javac documentation for additional information about javac option settings and functionality.
-C prefix and one with a -J prefix. Otherwise, no prefix is required.-C prefix to specify the -d or -encoding compiler options. Note that this also means that SQLJ and the compiler use the same settings for -d and -encoding.-C prefix for -depend, -deprecation, -g, -nowarn, -O, and -verbose.javac options, aside from those that are also SQLJ options (-classpath, -d, and -encoding) require the "compile." prefix if you set them in a properties file.-C on the command line or "compile." in a properties file).The following example (a single wraparound command line) uses the -C-bootclasspath, -C-extdirs, and -C-target options.
% sqlj -vm=/usr/local/packages/jdk1.2.2/bin/java -compiler-executable=/usr/local/packages/jdk1.2.2/bin/javac -C-bootclasspath=/usr/local/packages/jdk1.3.1/jre/lib/rt.jar -C-extdirs="" -C-target=1.1.8 Demo.sqlj
Profile customizer options--options for the customizer harness front end, the default Oracle customizer, and special customizers for debugging and deployment-time semantics-checking--are documented in "Customization Options and Choosing a Customizer". This is relevant for ISO standard code generation only (-codegen=iso).
The general sequence of events triggered by running the script sqlj was discussed in "SQLJ Translation Steps". This section will add some operational details to that discussion, as part of this overview of the command line.
Recall the typical general syntax for the command line:
sqlj <optionlist> filelist
When the sqlj script invokes a JVM, it passes all of its command-line arguments to the JVM, which later passes them elsewhere (such as to the Java compiler or profile customizer) as appropriate.
Use an equals sign (=) to specify option and flag settings, although for simplicity you do not have to specify =true to turn on a flag--typing the flag name alone will suffice. You must, however, specify =false to turn a flag off--a flag will not toggle from its previous value. For example:
-linemap=true or just -linemap to enable line-mapping
-linemap=false to disable line-mapping
|
Note: If the same option appears more than once on the command line (or in the properties file), then the last value is used. |
Option list arguments are used in the following ways:
-J, -C, or -P prefixes are SQLJ options (except for directly supported compiler options) and are passed to the SQLJ translator as the JVM invokes it.-J prefix are JVM options and are used by the JVM directly. Such options must be specified on the command line or in the SQLJ_OPTIONS environment variable. As with translator options, use an equals sign (=) in setting the option, such as:
-J-Djavac.pipe.output=true
If you want to set different classpath values for the Java compiler and for the JVM that runs SQLJ, you must use separate settings, one with a -C prefix and one with a -J prefix.
-C prefix are Java compiler options and are passed to the compiler as the JVM invokes it. Compiler options taking values require special support, which has been implemented for javac options, as described in "Option Support for javac". You can use an equals sign for these, as follows (though a space also works):
-C-bootclasspath=/usr/local/packages/jdk1.3.1/jre/lib/rt.jar
-P prefix are SQLJ profile customizer options and are passed to the customizer as the JVM invokes it (relevant only for ISO standard code generation, -codegen=iso). As with translator options, use an equals sign (=) in setting the option, such as:
-P-user=scott/tiger
Any profile customization other than what SQLJ performs automatically is considered an advanced feature and is covered in Appendix A, "Customization and Specialized Customizers".
The SQLJ front end parses the file list, processes wildcard characters, and expands file names. By default, files are processed as follows:
.sqlj files are processed by the SQLJ translator, Java compiler, and SQLJ profile customizer (profile customizer for -codegen=iso only)..java files are processed by the Java compiler and are also used by the SQLJ translator for type resolution..ser profiles and .jar files are processed only by the profile customizer (relevant only for -codegen=iso).Note that you can specify .sqlj files together with .java files on the command line, or you can specify .ser files together with .jar files, but you cannot mix the two categories. (See "JAR Files for Profiles" for details about how .jar files are processed.)
If you have .sqlj files and .java files with interdependencies (each requiring access to code in the others), then enter them all on the command line for a single execution of SQLJ. You cannot specify them for separate executions of SQLJ, because then SQLJ would be unable to resolve all the types.
|
Note: As an alternative to entering |
The SQLJ translator takes steps to try to prevent having multiple source files define the same class in the same location. If your command-line file list includes multiple references to the same .sqlj or .java file, all but the first reference are discarded from the command line. In addition, if you list a .java file and .sqlj file with the same base name and in the same location without using the -dir option, only the .sqlj file is processed. This processing also applies to wild-card file name characters.
Consider the following command-line examples, presuming that your current directory is /myhome/mypackage, which contains the files Foo.sqlj and Foo.java.
sqlj Foo.sqlj /myhome/mypackage/Foo.sqlj
These both refer to the same file, so the translator discards /myhome/mypackage/Foo.sqlj from the command line.
sqlj Foo.sqlj Foo.java
The translator discards Foo.java from the command line. Otherwise, this command line would result in the translator both writing to and reading from Foo.java in the same execution.
sqlj Foo.*
Again, the translator discards Foo.java from the command line. Otherwise, the translator would find both Foo.sqlj and Foo.java, which again would cause it to both write to and read from Foo.java in the same execution.
sqlj -dir=outdir -d=outclasses Foo.sqlj Foo.java
This is okay, because the generated Foo.java will be in the outdir subdirectory, while the Foo.java being read is in the /myhome/mypackage directory. Presuming that Foo.java and Foo.sqlj define classes in different packages, the .class files created by Java compilation will be placed in different subdirectories under the outclasses directory hierarchy.
This processing of the command line means that you can, for example, type the following command and have it execute without difficulty (with file references being automatically discarded as necessary):
sqlj *.sqlj *.java
This is convenient in many situations.
Below is a sample command line. This example uses some advanced concepts more fully explained later in this chapter, but is presented in the interest of showing a complete example of command-line syntax.
sqlj -J-Duser.language=ja -warn=none -J-prof -encoding=SJIS *Bar.sqlj Foo*.java
The sqlj script invokes a JVM, passes it the class name of the SQLJ translator, then passes it the command-line arguments. The JVM passes the SQLJ options to the translator and compiler. If there are any options for the JVM, as designated by -J, the script passes them to the JVM ahead of the translator class file name (just as you would type Java options prior to typing the class file name if you were invoking Java by hand). There is no customization in this example, because it uses the default Oracle-specific code generation.
After these steps are completed, the results are equivalent to the user having typed the following (presuming SushiBar.sqlj, DiveBar.sqlj, FooBar.java, and FooBaz.java were all in the current directory):
java -Duser.language=ja -prof sqlj.tools.Sqlj -warn=none -encoding=SJIS SushiBar.sqlj DiveBar.sqlj FooBar.java FooBaz.java
(This is one wraparound command line.)
For more information about how JVM options are handled, see "Options to Pass to the Java Virtual Machine (-J)".
You can use the SQLJ -n option (or, alternatively, -vm=echo) to echo the command line that the sqlj script would construct and pass to the SQLJ translator, without executing it. This includes settings in the SQLJ_OPTIONS environment variable as well as on the command line, but does not include settings in properties files. For more information, see "Command Line Echo without Execution (-n)".
You can use properties files, instead of the command line, to set options for the SQLJ translator, Java compiler, and SQLJ profile customizer (for ISO code generation).
In addition, if your Java compiler will be running in a separate JVM and you want to specify options to this JVM regarding operation of the compiler, then you can use properties files to supply such options. Such options are passed to the JVM at the time the compiler is run, after the SQLJ translation step. (It is more typical, however, to pass options to the JVM of the compiler by using the command-line -C-J prefix.)
You cannot use properties files to set the following SQLJ options, flags, and prefixes:
-classpath-help, -help-long, -help-alias, -C-help, -P-help-J-n-passes-props-version, -version-long-vmIt is not possible to use properties files to specify options to the JVM, for example, because properties files are read after the JVM is invoked.
Also note that in properties files you cannot use option abbreviations recognized on the command line for compatibility with loadjava (-e, -h, -p, -u, -v).
|
Notes: Discussion of SQLJ properties files applies only to client-side SQLJ, not server-side SQLJ. There is a different mechanism for specifying options to SQLJ in the server, and only a small subset of options are supported. For information, see "Option Support in the Server Embedded Translator". |
Option settings in a properties file are placed one per line. Lines with SQLJ options, compiler options, and customizer options can be interspersed. They are parsed by the SQLJ front end and processed appropriately.
Syntax for the different kinds of options is as follows:
sqlj." (including the period) instead of an initial hyphen; only options that start with this prefix are passed to the SQLJ translator. For example:
sqlj.warn=none sqlj.linemap=true
compile." (including the period) instead of "-C-"; options that start with this prefix are passed to the Java compiler. For example:
compile.verbose compile.bootclasspath=/usr/local/packages/jdk1.3.1/jre/lib/rt.jar
profile." (including the period) instead of "-P-"; only options that start with this prefix are passed to the profile customizer. For example:
profile.backup profile.user=scott/tiger
You can also specify options to a particular customizer by using "profile.C" as follows:
profile.Csummary profile.Coptparamdefaults=VAR%(50),LONG%(500),RAW_TYPE()
Any profile customization other than the default Oracle customization is considered an advanced feature and is covered in Appendix A, "Customization and Specialized Customizers".
#). For example:
# Comment line.
As on the command line, a flag can be enabled/disabled in a properties file with =true/=false, =on/=off, =1/=0, or =yes/=no. A flag can also be enabled simply by entering it without a setting, such as the following:
sqlj.linemap
|
Note: For consistency, it is best to always use the equals sign (=) in a properties file for options that take values, even though there are some circumstances where a space also works. |
The following are sample properties file entries:
# Set user and JDBC driver sqlj.user=scott sqlj.driver=oracle.jdbc.OracleDriver # Turn on the compiler verbose option compile.verbose
These entries are equivalent to having the following on the SQLJ command line:
sqlj -user=scott -driver=oracle.jdbc.OracleDriver -C-verbose
Following is a sample properties file that specifies settings for a connection context class SourceContext that you declared:
# JDBC driver sqlj.driver=oracle.jdbc.OracleDriver # Oracle 8.0.4 on spock.natdecsys.com sqlj.user@SourceContext=sde sqlj.password@SourceContext=fornow sqlj.url@SourceContext=jdbc:oracle:thin:@207.67.155.3:1521:nds # Warning settings sqlj.warn=all # Cache sqlj.cache=on
Regardless of whether a properties file is specified in the SQLJ command line, the SQLJ front end looks for files named "sqlj.properties". It looks for them in the Java home directory, the user home directory, and the current directory, in that order. It processes each sqlj.properties file it finds, overriding previously set options as it encounters new ones. Thus, options set in the sqlj.properties file in the current directory override those set in the sqlj.properties file in the user home directory or Java home directory.
Also see "Order of Precedence of Option Settings".
Oracle SQLJ supports use of an environment variable called SQLJ_OPTIONS as an alternative to the command line for setting SQLJ options. Any option referred to as "command-line only", meaning it cannot be set in a properties file, can also be set using the SQLJ_OPTIONS variable.
You can use the SQLJ_OPTIONS variable to set any SQLJ option, but it is intended especially for option settings to be passed to the JVM. And it is particularly useful for command-line-only options, such as -classpath, that you use repeatedly with the same setting.
Following is an example of a SQLJ_OPTIONS setting:
-vm=jview -J-verbose
When you use SQLJ_OPTIONS, SQLJ effectively inserts the SQLJ_OPTIONS settings, in order, at the beginning of the SQLJ command line, prior to any other command-line option settings.
SQLJ takes option settings in the following order. At each step, it overrides any previous settings for any given option.
sqlj.properties file in the Java home directory; if it finds one, it sets options as specified there.sqlj.properties file in the user home directory; if it finds one, it sets options as specified there.sqlj.properties file in the current directory; if it finds one, it sets options as specified there.SQLJ_OPTIONS environment variable and effectively prepends them to the beginning of the command line. It sets options as specified in SQLJ_OPTIONS.-props option and sets options as specified there.
Presume SQLJ is run as follows:
sqlj -user=scott -props=myprops.properties -dir=/home/java
And presume the file myprops.properties is in the current directory and contains the following entries:
sqlj.user=tony sqlj.dir=/home/myjava
These settings are processed as if they were inserted into the command line where the -props option was specified. Therefore, the tony entry takes precedence over the scott entry for the user option, but the /home/java entry takes precedence over the /home/myjava entry for the dir option.
This section documents the syntax and functionality of the basic flags and options you can specify in running SQLJ. These options allow you to run in a fairly standard mode of operation. For options that can also be specified in a properties file (such as sqlj.properties), that syntax is noted as well. (See "Properties Files for Option Settings".)
This discussion includes the following categories:
More advanced command-line flags and options are discussed in "Advanced Translator Options" and "Translator Support and Options for Alternative Environments".
The following basic options can be specified only on the SQLJ command line or, equivalently, in the SQLJ_OPTIONS environment variable. They cannot be specified in properties files.
The command-line-only flags (the -help flags, -version flags, and -n) do not support =true syntax. Enable them by typing only the flag name, as in the following example:
supported: sqlj -version-long ...
not supported: sqlj -version-long=true ...
|
Note: Additionally, there are advanced options, flags, and prefixes that can be set only on the command line or in |
The -props option specifies a properties file from which SQLJ can read option settings (an alternative to specifying option settings on the command line).
See "Properties Files for Option Settings" for information about the format of these files, the details of how they are used in relation to command-line options, and where SQLJ looks for default properties files.
-props=filename
-props=myprops.properties
n/a
n/a
none
For compatibility with the syntax of most JVMs and compilers, SQLJ recognizes the -classpath option if it is specified on the command line. In setting this option, you can use either a space, as with most JVMs or compilers, or "=", as with other SQLJ options. The following examples (both for a UNIX environment) demonstrate this:
-classpath=.:.$[ORACLE_HOME]/jdbc/lib/classes12.jar:$[ORACLE_HOME]/jdbc/lib/nls_charset12.jar
or:
-classpath .:.$[ORACLE_HOME]/jdbc/lib/classes12.jar:$[ORACLE_HOME]/jdbc/lib/nls_charset12.jar
The -classpath option sets the Java classpath for both the JVM and the Java compiler. If you do not want to use the same classpath for both, set them separately using the SQLJ -J and -C prefixes, described in "Prefixes that Pass Option Settings to Other Executables".
sqlj -classpath=<class_path>
sqlj -classpath=/jdbc-1.2.zip:/classes/bin
n/a
n/a
none
The following three settings of the -help flag, specified on the command-line, instruct SQLJ to display varying levels of information about SQLJ options:
You can enable this option by typing the desired setting on the command line as in the following examples:
sqlj -help
or:
sqlj -help-long
or:
sqlj -help-alias
No input-file translation is performed when you use the -help flag in any of these forms, even if you include file names and other options on the command line as well. SQLJ assumes that you either want to run the translator or you want help, but not both.
You can also receive information about the profile customizer or Java compiler, requesting help through the -P and -C prefixes as in the following examples. These prefixes are discussed in "Prefixes that Pass Option Settings to Other Executables". As with the -help flag, no translation is performed if you request customizer or compiler help.
sqlj -P-help sqlj -C-help
As with other command-line-only flags, -help (as well as -P-help and -C-help) does not support =true syntax. Enable it by typing only the desired flag setting.
|
Notes:
|
The most basic level of help is achieved by specifying the -help setting. This provides the following:
-help flag settings availableThis setting provides a complete list of SQLJ option information, including the following for each option:
int or String)This setting provides a synopsis of the command-line abbreviations supported for compatibility with the loadjava utility.
sqlj help_flag_settings
sqlj -help sqlj -help -help-alias sqlj -help-long sqlj -warn=none,null -help-long sqlj -help-alias
n/a
n/a
disabled
The following settings of the -version flag, specified on the command-line, instruct SQLJ to display varying levels of information about SQLJ and JDBC driver versions:
You can enable this option by typing the desired setting on the command line as in the following examples:
sqlj -version
or:
sqlj -version-long
No input-file translation is performed when you use the -version option, even if you include file names and other options on the command line. SQLJ assumes that you either want to run the translator or you want version information, but not both. Properties files and anything else you type on the command line are ignored.
As with other command-line-only flags, -version does not support =true syntax. Enable it by typing only the flag name.
The -version setting displays the SQLJ release number, such as "Oracle SQLJ 9.2".
The -version-long setting displays information about the SQLJ and SQLJ runtime library release and build versions, the JDBC driver release number if one can be found, and the Java environment. For example, if an Oracle JDBC driver is used, this option would display something such as "Oracle JDBC version 9.2 (9.2.0.0)".
This flag offers a good way to check your SQLJ installation and the JDBC and JDK versions you are using.
sqlj version_flag_settings
sqlj -version sqlj -version -version-long sqlj -version-long
n/a
n/a
disabled
The -n flag, specified on the command line, instructs the sqlj script to construct the full command line that would be passed to the SQLJ translator, including any SQLJ_OPTIONS settings, and echo it to the user without having the SQLJ translator execute it. This includes capturing and echoing the name of the JVM that would be launched to execute the SQLJ translator and echoing the full class name of the translator. This does not include settings from properties files.
This is useful in showing you the following:
-u and other abbreviations supported for loadjava compatibility)SQLJ_OPTIONS settings and command-line settingsThe -n option can appear anywhere on the command line or in the SQLJ_OPTIONS variable.
As with other command-line-only flags, -n does not support =true syntax. Enable it by typing only the flag name.
Consider the following sample scenario:
SQLJ_OPTIONS:
-user=scott/tiger@jdbc:oracle:thin:@ -classpath=/myclasses/bin
% sqlj -n -e SJIS myapp.sqlj
You would see the following echo:
java -classpath /myclasses/bin sqlj.tools.Sqlj -user=scott/tiger@jdbc:oracle:thin:@ -C-classpath=/myclasses/bin -encoding=SJIS myapp.sqlj
(This is all one wraparound line.)
|
Note:
|
-n
-n
n/a
n/a
disabled
The following option specifies encoding for SQLJ input and output source files:
These options specify where SQLJ output files are placed:
The -encoding option specifies the encoding to be applied to .sqlj and .java input files and .java generated files for globalization support. For compatibility with javac, you can use either a space or "=" in setting this option on the command line, as in the following examples:
-encoding=SJIS -encoding SJIS
If setting sqlj.encoding in a properties file, however, use "=", not a space.
When this option is specified, it is also passed to the Java compiler (unless the -compiler-encoding-flag is off), which uses it to specify encoding for .java files processed by the compiler.
Note the following:
-classpath and -d options described below, if you do use an "=" in setting the -encoding option, then it is stripped out when the option string is passed to the JVM and compiler. This is because JVMs and compilers do not support the "=" syntax in their option settings.loadjava utility, -e is recognized as equivalent to -encoding when specified on the command line. See "Options for loadjava Compatibility".-encoding option does not apply to Java properties files--sqlj.properties and connect.properties, for example. Properties files always use the encoding 8859_1. This is a feature of Java in general, not SQLJ in particular. You can, however, use Unicode escape sequences in a properties file. (You can use the native2ascii utility to create escape sequences for a natively encoded file--see "Using native2ascii for Source File Encoding".)-encoding=Java_character_encoding
-encoding=SJIS
sqlj.encoding=Java_character_encoding
sqlj.encoding=SJIS
setting in JVM system property file.encoding
The -d option specifies the root output directory for profiles generated by the SQLJ translator (relevant for ISO standard code generation, -codegen=iso), and is also passed to the Java compiler to specify the root output directory for .class files generated by the compiler. Whether profiles are generated as .ser files (default) or .class files (if the -ser2class option is enabled) is irrelevant for placement through the -d option.
Whenever a directory is specified, the output files are generated under this directory according to the package name, if applicable. For example, if you have source files in package a.b.c and specify directory /mydir, output files will be placed in the /mydir/a/b/c directory.
If you specify a relative directory path, this will be from your current directory.
For compatibility with javac, you can use either a space or "=" in setting this option on the command line, as in the following examples (both of which make /root the root directory for generated profile files):
-d=/root -d /root
If setting -d in a properties file, however, use "=", not a space (for example, sqlj.d=/root).
If your current directory is /root/home/mydir and you set the -d option to the relative directory path mysubdir/myothersubdir as follows, then /root/home/mydir/mysubdir/myothersubdir will be the root directory for generated profile files:
-d=mysubdir/myothersubdir
You can also use standard syntax such as a period for the current directory or two periods to go up a level (the second example immediately below will go up a level, then back down to a parallel directory called paralleldir):
-d=. -d=../paralleldir
If the -d option is empty or not specified, then .class files and .ser files generated by the translation process will be placed as follows:
.class file corresponding to a .java file that was generated by the translator is placed in the same directory as the generated .java file, which is according to the -dir option..class file corresponding to a .java file that you specified on the command line will be placed in the same directory as the .java file..ser file is placed in the same directory as the .sqlj source file from which it resulted.
-d=directory_path
-d=/topleveldir/mydir
sqlj.d=directory_path
sqlj.d=/topleveldir/mydir
none (.class files go with .java files; .ser files go with .sqlj files)
The -dir option specifies the root directory for .java files generated by the SQLJ translator.
Whenever a directory is specified, the output files are generated under this directory according to the package name, if applicable. For example, if you have source files in package a.b.c and specify directory /mydir, then output files will be placed in the /mydir/a/b/c directory.
If you specify a relative directory path, it will be from your current directory.
A simple example is as follows, which will make /root the root directory for generated .java files:
-dir=/root
If your current directory is /root/home/mydir and you set the -dir option to the relative directory path mysubdir/myothersubdir as follows:
-dir=mysubdir/myothersubdir
then /root/home/mydir/mysubdir/myothersubdir will be the root directory for generated .java files.
You can also use standard syntax such as a period for the current directory or two periods to go up a level (the second example immediately below will go up a level, then back down to a parallel directory called paralleldir):
-dir=. -dir=../paralleldir
If the -dir option is not specified, then files are generated under the same directory as the original .sqlj source file (not under the current directory).
If you specifically want the output directory to be the same as your .sqlj source directory (perhaps overriding other -dir settings, such as in properties files), then you can use the -dir option as follows:
-dir=
-dir=directory_path
-dir=/topleveldir/mydir
sqlj.dir=directory_path
sqlj.dir=/topleveldir/mydir
none (use directory of .sqlj source file)
You can use the following options for the database connection for online semantics-checking:
There is no requirement for the SQLJ translator to connect to the same database or schema as the application does at runtime. The connection information in application source code can be independent of the connection information in the SQLJ options. In fact, the deployment environment might be unavailable during development and testing.
Simple semantics-checking not involving a database connection is referred to as offline checking. The more thorough semantics-checking requiring a connection is referred to as online checking. Online checking offers one of the prime advantages of the SQLJ strong-typing paradigm--type incompatibilities that would normally result in runtime SQL exceptions are caught during translation, before users ever run the application.
The -user option enables online semantics-checking and specifies the user name (schema name) for the exemplar schema, which is the sample database schema that you provide to the translator for it to use in performing the checking. You can also use the -user option to specify the password and URL, as opposed to using the -password and -url options separately.
Note that there is no other flag to enable or disable online semantics-checking; SQLJ enables it or disables it according to the presence or absence of the -user option.
Discussion of the -user option is split into two categories--1) effect of -user when you are employing the default connection context class only; and 2) effect of -user when you are employing nondefault or multiple connection context classes. Nondefault connection context classes are discussed in "Connection Contexts".
General discussion of connection considerations, such as when to use multiple instances of the DefaultContext class and when to declare additional connection context classes, is in "Connection Considerations".
|
Notes:
|