You use the rmic
compiler to generate stub and skeleton class files using the Java Remote Method Protocol (JRMP) and stub and tie class files (IIOP protocol) for remote objects. The rmic
compiler generates Object Management Group (OMG) Interface Definition Language (IDL).
Synopsis
rmic [ options ] package-qualified-class-names
options
This represent the command-line options
for thermic
compiler. See Options for the rmic Compiler.
package-qualified-class-names
Class names that include their packages, for example, java.awt.Color
.
Description
Deprecation Note: Support for static generation of Java Remote Method Protocol (JRMP) stubs and skeletons has been deprecated. Oracle recommends that you use dynamically generated JRMP stubs instead, eliminating the need to use this tool for JRMP-based applications.
The rmic
compiler generates stub and skeleton class files using the JRMP 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 implementation class is a class that implements the interface java.rmi.Remote
. The class names in the rmic
command must be for classes that were compiled successfully with the javac
command and must be fully package qualified. For example, running the rmic
command on the class file name HelloImpl
as shown here creates the HelloImpl_Stub.class
file in the hello
subdirectory (named for the class's package):
rmic hello.HelloImpl
A skeleton for a remote object is a JRMP protocol server-side entity that 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 skeleton, but communicates with the client with the IIOP protocol.
A stub is a client-side proxy for a remote object that’s responsible for communicating method invocations on remote objects to the server where the actual remote object implementation resides. A client's reference to a remote object, therefore, is actually a reference to a local stub.
By default, the rmic
command generates stub classes that use the 1.2 JRMP stub protocol version only, as though the -v1.2
option were specified. See Options for the rmic Compiler.
A stub implements only the remote interfaces, and not local interfaces that the remote object also implements. Because a JRMP stub implements the same set of remote interfaces as the remote object, a client can use the Java programming language built-in operators for casting and type checking. For IIOP, the PortableRemoteObject.narrow
method must be used.
Options for the rmic Compiler
-bootclasspath path
Overrides the location of bootstrap class files.
-classpath path
Specifies the path the rmic
command uses to look up classes. This option overrides the default or the CLASSPATH
environment variable when it is set. Directories are separated by colons or semicolons, depending on your operating system. The following is the general format for path
:
Oracle Solaris, Linux, and OS X: .:your_path
, for example: .:/usr/local/java/classes
Windows: .;your_path
, for example: .;/usr/local/java/classes
-d directory
Specifies the root destination directory for the generated class hierarchy. You can use this option to specify a destination directory for the stub, skeleton, and tie files.
Oracle Solaris, Linux, and OS X: For example, the following command places the stub and skeleton classes derived from MyClass
into the directory /java/classes/exampleclass
:
rmic -d /java/classes exampleclass.MyClass
Windows: For example, the following command places the stub and skeleton classes derived from MyClass
into the directory C:\java\classes\exampleclass
:
rmic -d C:\java\classes exampleclass.MyClass
If the -d
option isn’t specified, then the default behavior is as though -d
was specified. The package hierarchy of the target class is created in the current directory, and stub/tie/skeleton files are placed within it.
-g
Enables the generation of all debugging information, including local variables. By default, only line number information is generated.
-idl
Causes the rmic
command to generate OMG IDL for the classes specified and any classes referenced. IDL provides a purely declarative, programming language-independent way to specify an API for an object. The IDL is used as a specification for methods and data that can be written in and called from any language that provides CORBA bindings. This includes Java and C++ among others.
When the -idl
option is used, other options also include:
The -always
or -alwaysgenerate
options force regeneration even when existing stubs/ties/IDL are newer than the input class.
The -factory
option uses the factory
keyword in generated IDL.
The -idlModule
from JavaPackage[.class]
toIDLModule
specifies IDLEntity
package mapping, for example: -idlModule
my.module my::real::idlmod
.
-idlFile
fromJavaPackage[.class] toIDLFile
specifies IDLEntity
file mapping, for example: -idlFile test.pkg.X TEST16.idl
.
-iiop
Causes the rmic
command 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 reference to a remote object is 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.
If you call the rmic
command with the -iiop
, then it generates stubs and ties that conform to this naming convention:
_implementationName_stub.class _interfaceName_tie.class
When you use the -iiop
option, other options also include:
The -always
or -alwaysgenerate
options force regeneration even when existing stubs/ties/IDL are newer than the input class.
The -nolocalstubs
option means don’t create stubs optimized for same-process clients and servers.
The -noValueMethods
option must be used with the -idl
option. The -noValueMethods
option prevents the addition of valuetype
methods and initializers to emitted IDL. These methods and initializers are optional for value types, and are generated unless the -noValueMethods
option is specified with the -idl
option.
The -poa
option changes the inheritance from org.omg.CORBA_2_3.portable.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 serves as the base class for all POA servant implementations and provides a number of methods that can be called by the application programmer, and methods that are called by the POA and that can be overridden by the user to control aspects of servant behavior. This behavior is based on the OMG IDL to Java Language Mapping Specification, CORBA V 2.3.1 ptc/00-01-08.pdf .
-Jargument
Used with any Java command, the -J
option passes the argument
that follows it (no spaces between the -J
and the argument) to the Java interpreter.
-keep
or -keepgenerated
Retains the generated .java
source files for the stub, skeleton, and tie classes and writes them to the same directory as the .class
files.
-nowarn
Turns off warnings. When the -nowarn
options is used, the compiler doesn’t print warnings.
-nowrite
Doesn’t write compiled classes to the file system.
-vcompat
(deprecated)Generates stub and skeleton classes that are compatible with both the 1.1 and 1.2 JRMP stub protocol versions. This option was the default in releases before 5.0. The generated stub classes use the 1.1 stub protocol version when loaded in a JDK 1.1 virtual machine and use the 1.2 stub protocol version when loaded into a 1.2 (or later) virtual machine. The generated skeleton classes support both 1.1 and 1.2 stub protocol versions. The generated classes are relatively large to support both modes of operation. Note: This option has been deprecated. See Description.
-verbose
Causes the compiler and linker to print messages about what classes are being compiled and what class files are being loaded.
-v1.1
(deprecated)Generates stub and skeleton classes for the 1.1 JRMP stub protocol version only. The -v1.1
option is useful only for generating stub classes that are serialization-compatible with existing, statically deployed stub classes generated by the rmic
command from JDK 1.1 that can’t be upgraded (and dynamic class loading isn’t being used). Note: This option has been deprecated. See Description.
-v1.2
(deprecated)(Default) Generates stub classes for the 1.2 JRMP stub protocol version only. No skeleton classes are generated because skeleton classes aren’t used with the 1.2 stub protocol version. The generated stub classes don’t work when they’re loaded into a JDK 1.1 virtual machine. Note: This option has been deprecated. See Description.