All VisiBroker for Java programmer's tools have both general and specific options. The specific options for each tool are listed in the section for the tool. All the options in the list are enabled by default and they are preceded by a hyphen (–). To turn off the default value, you can either prepend -no_ or remove the hyphen. For example, to display a “warning” if a #pragma is not recognized, the default value is:
Passes the java_option directly to the Java Virtual Machine. Specifies the classpath. The value entered here precedes the CLASSPATH ENV variable. Adds <jarfile> to the CLASSPATH before executing the VM. If no absolute path is specified, the jarfile is assumed to be relative to <launcher-location>/../lib. The path to the configuration file to be used by the launcher. If not specified, the default location is <install-dir>/bin/vbj.config (or vbjc.config for launcher vbjc). The idl2ir command takes an IDL file as input, binds itself to an interface repository server and populates the repository with the IDL constructs contained in filename. If the repository already contains an item with the same name as an item in the IDL file, the old item will be modified.
-U, -undefine <foo> The ir2idl command binds to the IR and prints the contents in IDL format.
Specifies strict adherence to OMG-standard code generation. The default is on. The compiler will complain upon occurrences of Micro Focus-proprietary syntax extensions in input IDL. This tool generates Java source code from an IDL source file. It is executed using the idl2java command.The idl2java command, a Java-based preprocessor, compiles an IDL source file and creates a directory structure containing the Java mappings for the IDL declarations. Typically, one IDL file will be mapped to many Java files because Java allows only one public interface or class per file. IDL file names must end with the .idl extension.
Specifies a comma-separated list of the Java compiler flags: "\-flag,arg[,.]". The first “–” character is escaped. Marks this package as sealed. Code will be generated in dest_pkg or default location. If you use a class that extends org.omg.CORBA.IDLEntity in some Java remote interface definition, it must have the following:
• an IDL file that contains the IDL definition for that type because the org.omg.CORBA.IDLEntity interface is a signature interface that marks all IDL data types mapped to Java.If you use a class that extends org.omg.CORBA.IDLEntity in some Java remote interface definition, use the -import <IDL files> directive in the java2idl tool's command line.For more information, refer to the CORBA 3.0 IDL2Java Specification located at
http://www.omg.org/.Using the option “–o” as shown in the above example, the three Java byte code files (Account, Client, Server) are output to a file, final.idl. By default, the output is displayed on the screen.The following options are available for java2idl.
If you use a class that extends org.omg.CORBA.IDLEntity in some Java remote interface definition, it must have the following:
• an IDL file that contains the IDL definition for that type because the org.omg.CORBA.IDLEntity interface is a signature interface that marks all IDL data types mapped to Java.If you use a class that extends org.omg.CORBA.IDLEntity in some Java remote interface definition, use the -import <IDL files> directive in the java2iiop tool's command line.For more information, refer to the CORBA 3.0 IDL2Java Specification located at
http://www.omg.org/.Use java2iiop if you have existing Java byte code that you wish to adapt to use distributed objects or if you do not want to write IDL. By using java2iiop, you can generate the necessary container classes, client stubs, and server skeletons from Java byte code.The java2iiop compiler does not support overloaded methods on CORBA interfaces.The following options are available for java2iiop.
Specifies the Java compiler to be used. This option is ignored if the -compile option is not set. Generates all methods defined in java.lang.Object methods, such as string and equals. The default is on. Generates stubs and skeletons for remote interfaces in the specified package to the org.omg.stub and the destination package respectively.
Java applications have certain limitations not faced by applications written in other languages. The vbj command provides options to work around some of these limitations, and it is the preferred method to launch VisiBroker applications. The vbj command performs the following actions:
-classicvm
-hotspotvm / -clientvm
-servervm Modifies the classpath. The value of this argument is either appended to (/a), prepended to (/p), or completely replaces (/r) any existing classpath setting in the environment. Only the last occurrence of the classpath family argument is honored. Note that -VBJclasspath is equivalent to -classpath/p and
-VBJaddJar ir equivalent to -classpath/a. Prints an equivalent Java command. This is useful when vbj launcher is not required and the application is executed through java launcher. Passes the property name and value pair into the Java Virtual Machine as a System Property by adding it as a
-D<name>[=<value>] parameter to the executed “java.”.
• The vbjc command supports the command line options described in the following table.
Specifies the classpath. Precedes CLASSPATH environment variable. Appends <install-dir>/lib/<jarfile> to the CLASSPATH before executing the VM. If no absolute path is specified, the jarfile is assumed to be relative to <launcher-location>/../lib. Specifies the path to the configuration file to be used by the launcher. If not specified, the default location is <install-dir>/bin/vbj.config|vbjc.config. Overwrites the default javac main class.
1 JAR and ZIP files in the patches directory ($VBROKERDIR/lib/patches/) (Note that the patches directory is not automatically created under the $VBROKERDIR/lib/ directory. It has to be created by the user explicitly.)
2
3
4 The classpath specified in -classpath/a
6 JAR files added using VBJaddJar and assumed to be located in the
<launcher location>/../lib directory if no absolute path is specified
7 Classpath added using addpath directive in the configuration file
8 JAR files added using addjars directive in the configuration fileThe merged classpath is passed to the Java Virtual Machine using -Djava.class.path.
2 Using the information specified through javahome directive in the configuration file (the default configuration file for vbj is vbj.config).The above procedure can be overridden using the -VBJjavavm or -javahome (only supported in vbj) option. With -VBJjavavm either the name of the VM or the full path to the VM can be specified. The option -javahome has the same semantics as the javahome configuration file directive. Note that if no VM is found using the -VBJjavavm or -javahome options, no further search is carried out to locate the default JVM, and the program terminates with an error.