rmic(1)rmic(1)NAMErmic - Java RMI stub compiler
SYNOPSISrmic [ options ] package-qualified-class-names
DESCRIPTION
The rmic compiler generates stub and skeleton class files (JRMP proto‐
col) and stub and tie class files (IIOP protocol) for remote objects.
These class files are generated from compiled Java programming language
classes that are remote object implementation classes. A remote imple‐
mentation class is a class that implements the interface
java.rmi.Remote. The classes named in the rmic command must be for
classes that have been compiled successfully with the javac(1) command
and be fully package-qualified. For example, running rmic on the class
file name HelloImpl as shown here:
rmic hello.HelloImpl
creates the HelloImpl_Stub.class file in the hello subdirectory (named
for the class's package).
A skeleton for a remote object is a JRMP protocol server-side entity
has a method that dispatches calls to the remote object implementation.
A tie for a remote object is a server-side entity similar to a skele‐
ton, but which communicates with the client using the IIOP protocol.
A stub is a proxy for a remote object that is responsible for forward‐
ing method invocations on remote objects to the server where the actual
remote object implementation resides. A client's reference to a remote
object is actually a reference to a local stub.
By default, rmic generates stub classes that use the 1.2 JRMP stub pro‐
tocol version only, as if the -v1.2 option had been specified. (Note
that the -vcompat option was the default in releases prior to 1.5.) Use
the -iiop option to generate stub and tie classes for the IIOP proto‐
col.
The stub implements only the remote interfaces, not local interfaces
also implemented by the remote object. Because the stub implements
exactly the same set of remote interfaces as the remote object, a
client can use the Java language's built-in operators for casting and
type-checking. For IIOP, the PortableRemoteObject.narrow method must
be used.
OPTIONS-bootclasspath path
Overrides location of bootstrap class files.
-classpath path
Specifies the path rmic uses to look up classes. Set‐
ting this option overrides the default or the CLASSPATH
environment variable. Directories are separated by
colons. Thus, the general format for path is:
.:<your_path>
For example:
.:/usr/local/java/classes
-d directory Specifies the root directory of the class hierarchy.
You can use this option to specify a destination direc‐
tory for the stub, skeleton, and tie files. For exam‐
ple, the command
rmic-d /java/classes foo.MyClass
would place the stub and skeleton classes derived from MyClass into the
directory /java/classes/foo. If the -d option is not specified, the
default behavior is as if "-d ." were specified: the package hierarchy
of the target class is created in the current directory, and
stub/tie/skeleton files are placed within it. (Note that in some previ‐
ous versions of rmic, if -d was not specified, then the package hierar‐
chy was not created, and all of the output files were placed directly
in the current directory.)
-extdirs path Overrides location of installed extensions.
-g Enables generation of all debugging information, includ‐
ing local variables. By default, only line number infor‐
mation is generated.
-idl Causes rmic to generate OMG IDL for the classes speci‐
fied and any classes referenced. IDL provides a purely
declarative, programming language-independent way of
specifying an object's API. The IDL is used as a speci‐
fication for methods and data that can be written in and
invoked from any language that provides CORBA bindings.
This includes Java and C++ among others. When the -idl
option is used, other options also include:
-always or -alwaysgenerate
Forces re-generation even when existing
stubs/ties/IDL are newer than the input class.
-factory
Uses factory keyword in generated IDL.
-idlModule fromJavaPackage[.class] toIDLModule
Specifies IDLEntity package mapping. For example:
-idlModule foo.bar
my::real::idlmod.
-idlFile fromJavaPackage[.class] toIDLFile
Specifies IDLEntity file mapping. For example:
-idlFile test.pkg.X TEST16.idl
-iiop Causes rmic to generate IIOP stub and tie classes,
rather than JRMP stub and skeleton classes. A stub
class is a local proxy for a remote object and is used
by clients to send calls to a server. Each remote
interface requires a stub class, which implements that
remote interface. A client's reference to a remote
object is actually a reference to a stub. Tie classes
are used on the server side to process incoming calls
and dispatch the calls to the proper implementation
class. Each implementation class requires a tie class.
Invoking rmic with -iiop generates stubs and ties that
conform to this naming convention:
_<implementationName>_stub.class
_<interfaceName>_tie.class
When the -iiop option is used, other options also
include:
-always or -alwaysgenerate
Forces re-generation even when existing
stubs/ties/IDL are newer than the input class.
-nolocalstubs
Does not create stubs optimized for same-process
clients and servers.
-noValueMethods
Must be used with the -idl option. Prevents addi‐
tion of valuetype methods and initializers to emit‐
ted IDL. These methods and initializers are
optional for valuetypes and are generated unless
the -noValueMethods option is specified when using
the -idl option.
-poa
Changes the inheritance from org.omg.CORBA_2_3.por‐
table.ObjectImpl to org.omg.PortableServer.Servant.
The PortableServer module for the Portable Object
Adapter (POA) defines the native Servant type. In
the Java programming language, the Servant type is
mapped to the Java org.omg.PortableServer.Servant
class. It server as the base class for all POA ser‐
vant implementation and provides a number of meth‐
ods that may be invoked by the application program‐
mer, as well as methods which are invoked by the
POA itself and may be overridden by the user to
control aspects of servant behavior. Based on the
OMG IDL to Java Language Mapping Specfication,
CORBA V 2.3.1 ptc/00-01-08.pdf.
-Joption
Pass option to the Java virtual
machine, where option is one of the
options described on the man page for
the java application launcher,
java(1). For example, -J-Xms48m sets
the startup memory to 48 megabytes.
It is a common convention for -J to
pass options to the underlying vir‐
tual machine.
-keepgenerated Retains the generated .java source files
for the stub, skeleton, and/or tie classes
and writes them to the same directory as
the .class files
-nowarn Turns off warnings. If used, the compiler
does not print warnings.
-vcompat Generates stub and skeleton classes com‐
patible with both the 1.1 and 1.2 JRMP
stub protocol versions. (This option was
the default in releases prior to 1.5.) The
generated stub classes will use the 1.1
stub protocol version when loaded in a JDK
1.1 virtual machine and will use the 1.2
stub protocol version when loaded into a
1.2 (or later) virtual machine. The gener‐
ated skeleton classes will support both
1.1 and 1.2 stub protocol versions. The
generated classes are relatively large in
order to support both modes of operation.
-verbose Causes the compiler and linker to display
messages about the classes being compiled
and what class files being loaded.
-v1.1 Creates stubs and skeletons for JDK 1.1
stub protocol version only. Note that
this option is only useful for generating
stub classes that are serialization-com‐
patible with pre-existing, statically-
deployed stub classes that were generated
by the rmic tool from JDK 1.1 and that
cannot be upgraded (and dynamic class
loading is not being used).
-v1.2 (default) Generates stub classes for the
1.2 JRMP stub protocol version only. No
skeleton classes are generated with this
option because skeleton classes are not
used with the 1.2 stub protocol version.
The generated stub classes will not work
if they are loaded into a JDK 1.1 virtual
machine.
ENVIRONMENT VARIABLES
CLASSPATH Used to provide the system with a path to
user-defined classes. Directories are
separated by colons. For example,
.:/usr/local/java/classes
SEE ALSOjava(1), javac(1) CLASSPATH
23 June 2004 rmic(1)
