VisiBroker for Java Developer’s Guide : Programmer tools for Java

Programmer tools for Java
This chapter describes the programmer tools offered by VisiBroker for Java. In this section, command syntax consists of the commands, the arguments necessary to execute them, and command-line options. Some commands take no arguments, but their options are provided.
The VisiBroker for Java tools provide features which give you greater flexibility in configuring your applications, such as setting classpath and ORB properties. VisiBroker provides a configuration file-based system that lets the user specify the configuration. In addition, in VisiBroker version 6.5 and later, all of these tools are invoked using launchers that are natively built. Previously, UNIX-based launchers were script-based and provided very limited functionality for configuration.
Options
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:
warn_unrecognized_pragmas
To turn off the default, use the following option:
-no_warn_unrecognized_pragmas
The general options available to all programmer tools are provided in the following section.
General options
The following options are common to all programmer tools:
Passes the java_option directly to the Java Virtual Machine.
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.
idl2ir
This tool allows you to populate an interface repository (IR) with objects defined in an Interface Definition Language (IDL) source file. It is executed using the idl2ir command.
Syntax
idl2ir [options] {filename}
Example
idl2ir -irep my_repository -replace java_examples/bank/Bank.idl
Description
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.
Keywords
The keyword contains both the options listed below and the IDL input files to be processed.
Options
The following options are available for idl2ir.
Defines a preprocessor macro foo, optionally with a value bar.
Creates built-in Type ::TypeCode or ::Principal. The default is on.
ir2idl
This tool allows you to create an Interface Definition Language (IDL) source file with objects from an interface repository. It is executed with the ir2idl command.
Syntax
ir2idl [options] filename
Example
ir2idl -irep my_repository -o my_file
Description
The ir2idl command binds to the IR and prints the contents in IDL format.
Keywords
The keyword contains both the options listed below.
Options
The following options are available for ir2idl.
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.
idl2java
This tool generates Java source code from an IDL source file. It is executed using the idl2java command.
Syntax
idl2java [options] {filename}
Example
idl2java -no_tie Bank.idl
Description
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.
Keywords
The keyword contains both the options listed below and the IDL source file(s) to be processed.
Options
The following options are available for idl2java:
Defines a preprocessor macro foo, optionally with a value bar.
Specifies a comma-separated list of the Java compiler flags: "\-flag,arg[,.]". The first “–” character is escaped.
Creates built-in Type ::TypeCode or ::Principal. The default is on.
Suppresses the generation ofbind() methods in the generated Helper class. The default is off.
java2idl
This command generates an IDL from a Java class file (in Java byte code). You can enter one or more Java classes (in byte codes). If you enter more than one class name, make sure you include spaces in between the class names.
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/.
Note
To use this command, you must have a virtual machine supporting JDK 1.3 or later.
Syntax
java2idl [options] {filename}
Example
java2idl -o final.idl Account Client Server
Description
Use this command when you want to generate an IDL from your Java byte code. You might want to use this when you have existing Java byte code and want to create an IDL file from it so it can be used with some other programming language like C++, COBOL, or Smalltalk.
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.
Keywords
The keyword contains both the options listed below and the Java byte code file(s) to be processed.
Options
The following options are available for java2idl.
Defines a preprocessor macro foo, optionally with a value bar.
java2iiop
This command allows you to use the Java language to define IDL interfaces instead of using IDL. You can enter one or more Java class names (in Java byte code). If you enter more than one class name, make sure you include spaces in between the class names. Use fully scoped class names.
Note
To use this command, you must have a Java Virtual Machine supporting JDK 1.3 or later.
 
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/.
Syntax
java2iiop [options] {class name}
Example
java2iiop -no_tie Account Client Server
Description
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.
Note
The java2iiop compiler does not support overloaded methods on CORBA interfaces.
Keywords
The keyword contains both the options listed below and the Java byte code file(s) to be processed.
Options
The following options are available for java2iiop.
Defines a preprocessor macro foo, optionally with a value bar.
Suppresses the generation of the _example classes. The default is off.
Generates _tie classes. The default is on.
Suppresses the generation of bind() methods in the generated Helper class. The default is on.
Creates built-in Type ::TypeCode or ::Principal. The default is on.
Maps array of IDLEntity to boxedIDL in boxedRMI. The default is off.
Generates all methods defined in java.lang.Object methods, such as string and equals. The default is on.
vbj
This command starts the local Java interpreter.
Syntax
vbj [options] [arguments normally sent to java VM] {class} [arg1 arg2 ...]
Where:
Example
vbj Server
Description
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:
The following options are available for vbj.
-classicvm
-hotspotvm
/ -clientvm
-servervm
Prints an equivalent Java command. This is useful when vbj launcher is not required and the application is executed through java launcher.
vbjc
This command is used to compile Java source code that can import VisiBroker classes. When called, it:
Launches javac main class: com.sun.tools.javac.Main.
Syntax
vbjc [arguments normally passed to javac]
Example
vbjc Server.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.
Overwrites the default javac main class.
Specifying the classpath
The following sources are merged in the following order:
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
The classpath specified in -VBJclasspath, -classpath/p, or -classpath/r
3
The $CLASSPATH exported in the environment (if -classpath/r is not specified)
4
5
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 file
9
The merged classpath is passed to the Java Virtual Machine using -Djava.class.path.
Specifying the JVM
By default the JVM is located as follows:
1
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.
idl2wsj