1rmic(1) Remote Method Invocation (RMI) Tools rmic(1)
2
6 rmic - Generates stub, skeleton, and tie classes for remote objects
7 that use the Java Remote Method Protocol (JRMP) or Internet Inter-Orb
8 protocol (IIOP). Also generates Object Management Group (OMG) Interface
9 Definition Language (IDL)
10
12 rmic [ options ] package-qualified-class-names
13 options
16 The command-line options. See Options.
17 package-qualified-class-names
19 Class names that include their packages, for example,
20 java.awt.Color.
21
23 Deprecation Note: Support for static generation of Java Remote Method
24 Protocol (JRMP) stubs and skeletons has been deprecated. Oracle
25 recommends that you use dynamically generated JRMP stubs instead,
26 eliminating the need to use this tool for JRMP-based applications. See
27 the java.rmi.server.UnicastRemoteObject specification at
28 http://docs.oracle.com/javase/8/docs/api/java/rmi/server/UnicastRemoteObject.html
29 for further information.
30 The rmic compiler generates stub and skeleton class files using the
32 Java Remote Method Protocol (JRMP) and stub and tie class files (IIOP
33 protocol) for remote objects. These class files are generated from
34 compiled Java programming language classes that are remote object
35 implementation classes. A remote implementation class is a class that
36 implements the interface java.rmi.Remote. The class names in the rmic
37 command must be for classes that were compiled successfully with the
38 javac command and must be fully package qualified. For example, running
39 the rmic command on the class file name HelloImpl as shown here creates
40 the HelloImpl_Stub.classfile in the hello subdirectory (named for the
41 class's package):
42 rmic hello.HelloImpl
44 A skeleton for a remote object is a JRMP protocol server-side entity
46 that has a method that dispatches calls to the remote object
47 implementation.
48 A tie for a remote object is a server-side entity similar to a
50 skeleton, but communicates with the client with the IIOP protocol.
51 A stub is a client-side proxy for a remote object that is responsible
53 for communicating method invocations on remote objects to the server
54 where the actual remote object implementation resides. A client's
55 reference to a remote object, therefore, is actually a reference to a
56 local stub.
57 By default, the rmic command generates stub classes that use the 1.2
59 JRMP stub protocol version only, as though the -v1.2 option was
60 specified. The -vcompat option was the default in releases before 5.0.
61 Use the -iiop option to generate stub and tie classes for the IIOP
62 protocol. See Options.
63 A stub implements only the remote interfaces, and not any local
65 interfaces that the remote object also implements. Because a JRMP stub
66 implements the same set of remote interfaces as the remote object, a
67 client can use the Java programming language built-in operators for
68 casting and type checking. For IIOP, the PortableRemoteObject.narrow
69 method must be used.
70
72 -bootclasspath path
73 Overrides the location of bootstrap class files.
74 -classpath path
76 Specifies the path the rmic command uses to look up classes.
77 This option overrides the default or the CLASSPATH environment
78 variable when it is set. Directories are separated by colons.
79 The general format for path is: .:<your_path>, for example:
80 .:/usr/local/java/classes.
81 -d directory
83 Specifies the root destination directory for the generated class
84 hierarchy. You can use this option to specify a destination
85 directory for the stub, skeleton, and tie files. For example,
86 the following command places the stub and skeleton classes
87 derived from MyClass into the directory
88 /java/classes/exampleclass.
89 rmic -d /java/classes exampleclass.MyClass
91 If the -d option is not specified, then the default behavior is
95 as if -d . was specified. The package hierarchy of the target
96 class is created in the current directory, and stub/tie/skeleton
97 files are placed within it. In some earlier releases of the rmic
98 command, if the -d option was not specified, then the package
99 hierarchy was not created, and all of the output files were
100 placed directly in the current directory.
101 -extdirs path
103 Overrides the location of installed extensions.
104 -g
106 Enables the generation of all debugging information, including
107 local variables. By default, only line number information is
108 generated.
109 -idl
111 Causes the rmic command to generate OMG IDL for the classes
112 specified and any classes referenced. IDL provides a purely
113 declarative, programming language-independent way to specify an
114 API for an object. The IDL is used as a specification for
115 methods and data that can be written in and called from any
116 language that provides CORBA bindings. This includes Java and
117 C++ among others. See Java IDL: IDL to Java Language Mapping at
118 http://docs.oracle.com/javase/8/docs/technotes/guides/idl/mapping/jidlMapping.html
119 When the -idl option is used, other options also include:
121 · The -always or -alwaysgenerate options force regeneration even
123 when existing stubs/ties/IDL are newer than the input class.
124 · The -factory option uses the factory keyword in generated IDL.
126 · The -idlModule from JavaPackage[.class]toIDLModule specifies
128 IDLEntity package mapping, for example: -idlModulemy.module
129 my::real::idlmod.
130 · -idlFilefromJavaPackage[.class] toIDLFile specifies IDLEntity
132 file mapping, for example: -idlFile test.pkg.X TEST16.idl.
133 -iiop
136 Causes the rmic command to generate IIOP stub and tie classes,
137 rather than JRMP stub and skeleton classes. A stub class is a
138 local proxy for a remote object and is used by clients to send
139 calls to a server. Each remote interface requires a stub class,
140 which implements that remote interface. A client reference to a
141 remote object is a reference to a stub. Tie classes are used on
142 the server side to process incoming calls, and dispatch the
143 calls to the proper implementation class. Each implementation
144 class requires a tie class.
145 If you call the rmic command with the -iiop, then it generates
147 stubs and ties that conform to this naming convention:
148 _<implementationName>_stub.class
150 _<interfaceName>_tie.class
151 · When you use the -iiop option, other options also include:
154 · The -always or -alwaysgenerate options force regeneration even
156 when existing stubs/ties/IDL are newer than the input class.
157 · The -nolocalstubs option means do not create stubs optimized
159 for same-process clients and servers.
160 · The -noValueMethods option must be used with the -idl option.
162 The -noValueMethods option prevents the addition of valuetype
163 methods and initializers to emitted IDL. These methods and
164 initializers are optional for valuetypes, and are generated
165 unless the -noValueMethods option is specified with the -idl
166 option.
167 · The -poa option changes the inheritance from
169 org.omg.CORBA_2_3.portable.ObjectImpl to
170 org.omg.PortableServer.Servant. The PortableServer module for
171 the Portable Object Adapter (POA) defines the native Servant
172 type. In the Java programming language, the Servant type is
173 mapped to the Java org.omg.PortableServer.Servant class. It
174 serves as the base class for all POA servant implementations
175 and provides a number of methods that can be called by the
176 application programmer, and methods that are called by the POA
177 and that can be overridden by the user to control aspects of
178 servant behavior. Based on the OMG IDL to Java Language
179 Mapping Specification, CORBA V 2.3.1 ptc/00-01-08.pdf..RE
180 -J
183 Used with any Java command, the -J option passes the argument
184 that follows the -J (no spaces between the -Jand the argument)
185 to the Java interpreter
186 -keep or -keepgenerated
188 Retains the generated .java source files for the stub,
189 skeleton, and tie classes and writes them to the same
190 directory as the.class files.
191 -nowarn
193 Turns off warnings. When the -nowarn options is used. The
194 compiler does not print out any warnings.
195 -nowrite
197 Does not write compiled classes to the file system.
198 -vcompat (deprecated)
200 Generates stub and skeleton classes that are compatible with
201 both the 1.1 and 1.2 JRMP stub protocol versions. This option
202 was the default in releases before 5.0. The generated stub
203 classes use the 1.1 stub protocol version when loaded in a JDK
204 1.1 virtual machine and use the 1.2 stub protocol version when
205 loaded into a 1.2 (or later) virtual machine. The generated
206 skeleton classes support both 1.1 and 1.2 stub protocol
207 versions. The generated classes are relatively large to
208 support both modes of operation. Note: This option has been
209 deprecated. See Description.
210 -verbose
212 Causes the compiler and linker to print out messages about
213 what classes are being compiled and what class files are being
214 loaded.
215 -v1.1 (deprecated)
217 Generates stub and skeleton classes for the 1.1 JRMP stub
218 protocol version only. The -v1.1 option is only useful for
219 generating stub classes that are serialization-compatible with
220 preexisting, statically deployed stub classes that were
221 generated by the rmic command from JDK 1.1 and that cannot be
222 upgraded (and dynamic class loading is not being used). Note:
223 This option has been deprecated. See Description.
224 -v1.2 (deprecated)
226 (Default) Generates stub classes for the 1.2 JRMP stub
227 protocol version only. No skeleton classes are generated
228 because skeleton classes are not used with the 1.2 stub
229 protocol version. The generated stub classes do not work when
230 they are loaded into a JDK 1.1 virtual machine. Note: This
231 option has been deprecated. See Description.
232
234 CLASSPATH
235 Used to provide the system a path to user-defined classes.
236 Directories are separated by colons, for example:
237 .:/usr/local/java/classes.
238
240 · javac(1)
241 · java(1)
243 · Setting the Class Path
245JDK 8 21 November 2013 rmic(1)