|idltojava||Java 2 SDK 1.2 and later|
|The Java IDL Compiler|
idltojava [ options ] IDLfiles
Description: The idltojava compiler generates Java source files from IDL interface, module, and type descriptions. The compiler ostensibly follows the standard IDL Java mapping defined by the OMG. Note that according to the standard mapping, a single IDL construct may result in several Java constructs being generated. A single IDL interface, for example, generates five Java source files.
Description: The idltojava compiler performs a preprocessing stage during compilation, much like a C or C++ compiler. The preprocessor accepts #define, #undefine, #include, and #pragma directives for preprocessing. Some of the compiler options are related to this preprocessing stage. The #pragma directives that idltojava accepts are:
Description: Note that #pragma directives must appear at the beginning of the IDL file.
Define the named symbol with the given value during preprocessing of the IDL file. This command, for example:
% idltojava -DmaxArray=10 myFile.idl
causes the preprocessor to have the symbol maxArray defined as specified during preprocessing of the IDL file myFile.idl.
This option turns on and off execution flags for the compiler. The option with just the flag name turns on the named flag, and the option with no- followed by the flag name turns off the named flag. There is no space after the -f in both cases.
The possible flags are listed in the following table:
Compile the IDL without considering case when comparing identifiers.
Generate client-side Java stubs for the IDL entities encountered.
Run a C/C++ preprocessor over the IDL files before compilation. An error is reported and compilation stops if the preprocessor is not found. Affected by the CPP and CPPARGS environment variables described in the next section, or uses the defaults if none given.
Print the value of all the flags used for compilation.
Print a list of the command-line options used for compilation.
Generate Java code for any IDL files included by #include directives.
Generate portable stub and skeleton Java classes (e.g., code that uses the CORBA portability layer provided in the org.omg.CORBA.portable package).
Generate server-side Java skeletons for the IDL entities encountered.
Generate xxxTie and xxxOperations classes for each server skeleton, thus making them eligible for use in delegation-based operation.
Print extensive messages on the compilation procedure.
Print the version number and timestamp for the idltojava compiler in use.
Write the generated Java source files to the destination directory. If this flag is off, the compiler is acting as simply an IDL syntax checker.
The given path should be used as the destination for the generated Java source files. If a Java class is mapped to a Java package, the compiler creates subdirectories in the given destination automatically to store the Java files. There is a space between the -j and the path.
The named symbol should be undefined when the compiler starts preprocessing the IDL files. There is no space between the -U and the symbol name.
The full path to a C/C++ pre-processor to use when the cpp flag is on during compilation. If this variable is not set in the environment, the idltojava compiler uses a default of /usr/ccs/lib/cpp on Solaris and the Microsoft Visual C++ preprocessor on Windows systems.
A list of arguments to be passed to the preprocessor.
Bugs: As of this writing, Sun still has not released a final version of idltojava to correspond to the final Java IDL API included in the Java SDK 1.2. The current available version is the early-access version, which has the following notable bugs:
|tnameserv||Java 2 SDK 1.2 and later|
|The Java IDL Naming Service Daemon|
tnameserv [ options ]
Description: The tnameserv daemon is the CORBA Naming Service daemon provided with Java IDL. The Naming Service allows remote CORBA objects to be bound to names with the naming directory of the service. Remote clients can connect to the Naming Service through standard CORBA APIs and ask for references to these objects by name or browse through the objects bound to names in the directory.
Description: The daemon should be run in the background. The tnameserv implementation of the Naming Service is a nonpersistent one (i.e., bindings created and stored in the naming context are only valid during the lifetime of the tnameserv daemon).
Copyright © 2001 O'Reilly & Associates. All rights reserved.