NAME

rmic - Generates stub, skeleton, and tie classes for remote objects that use the Java Remote Method Protocol (JRMP) or Internet Inter-Orb protocol (IIOP). Also generates Object Management Group (OMG) Interface Definition Language (IDL)

SYNOPSIS

rmic [ options ] package-qualified-class-names

options

The command-line options. See Options.

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. See the java.rmi.server.UnicastRemoteObject specification at http://docs.oracle.com/javase/8/docs/api/java/rmi/server/UnicastRemoteObject.html for further information.

The rmic compiler generates stub and skeleton class files using the Java Remote Method Protocol (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.classfile 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 is 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 was specified. The -vcompat option was the default in releases before 5.0. Use the -iiop option to generate stub and tie classes for the IIOP protocol. See Options.

A stub implements only the remote interfaces, and not any 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

-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. The general format for path is: .:<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. 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

If the -d option is not specified, then the default behavior is as if -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. In some earlier releases of the rmic command, if the -d option was not specified, then the package hierarchy was not created, and all of the output files were placed directly in the current directory.

-extdirs path

Overrides the location of installed extensions.

-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. See Java IDL: IDL to Java Language Mapping at http://docs.oracle.com/javase/8/docs/technotes/guides/idl/mapping/jidlMapping.html

When the -idl option is used, other options also include:

-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

ENVIRONMENT VARIABLES

CLASSPATH

Used to provide the system a path to user-defined classes. Directories are separated by colons, for example: .:/usr/local/java/classes.

SEE ALSO

•

javac(1)

•

java(1)

•

Setting the Class Path