You use the
rmic compiler to generate stub and skeleton class files using the Java Remote Method Protocol (JRMP).
rmic [ options ] package-qualified-class-names
This represents the command-line
rmiccompiler. See Options for the rmic Compiler.
Class names that include their packages, for example,
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.
rmic compiler generates stub and skeleton class files using the JRMP.
The rmic compiler has been updated to remove the
-iiop options and can no longer generate IDL or IIOP stubs and tie classes.
JRMP 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):
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 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.
Options for the rmic Compiler
Overrides the location of bootstrap class files.
Specifies the path the
rmiccommand uses to look up classes. This option overrides the default or the
CLASSPATHenvironment variable when it is set. Directories are separated by colons or semicolons, depending on your operating system. The following is the general format for
Oracle Solaris, Linux, and macOS:
.:your_path, for example:
.;your_path, for example:
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 macOS: For example, the following command places the stub and skeleton classes derived from
MyClassinto the directory
rmic -d /java/classes exampleclass.MyClass
Windows: For example, the following command places the stub and skeleton classes derived from
MyClassinto the directory
rmic -d C:\java\classes exampleclass.MyClass
-doption isn’t specified, then the default behavior is as though
-dwas specified. The package hierarchy of the target class is created in the current directory, and stub/tie/skeleton files are placed within it.
Enables the generation of all debugging information, including local variables. By default, only line number information is generated.
Used with any Java command, the
-Joption passes the
argumentthat follows it (no spaces between the
-Jand the argument) to the Java interpreter.
Retains the generated
.javasource files for the stub, skeleton, and tie classes and writes them to the same directory as the
Turns off warnings. When the
-nowarnoption is used, the compiler doesn’t print warnings.
Doesn’t write compiled classes to the file system.
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.
Causes the compiler and linker to print messages about what classes are being compiled and what class files are being loaded.
Generates stub and skeleton classes for the 1.1 JRMP stub protocol version only. The
-v1.1option is useful only for generating stub classes that are serialization-compatible with existing, statically deployed stub classes generated by the
rmiccommand from JDK 1.1 that can’t be upgraded (and dynamic class loading isn’t being used).
(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.