1rmic(1)              Remote Method Invocation (RMI) Tools              rmic(1)
2
3
4

NAME

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

SYNOPSIS

12       rmic [ options ] package-qualified-class-names
13
14
15       options
16              The command-line options. See Options.
17
18       package-qualified-class-names
19              Class names that include their packages, for example,
20              java.awt.Color.
21

DESCRIPTION

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
31       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
43       rmic hello.HelloImpl
44
45       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
49       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
52       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
58       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
64       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

OPTIONS

72       -bootclasspath path
73              Overrides the location of bootstrap class files.
74
75       -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
82       -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
90              rmic -d /java/classes exampleclass.MyClass
91
92
93
94              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
102       -extdirs path
103              Overrides the location of installed extensions.
104
105       -g
106              Enables the generation of all debugging information, including
107              local variables. By default, only line number information is
108              generated.
109
110       -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
120              When the -idl option is used, other options also include:
121
122              · The -always or -alwaysgenerate options force regeneration even
123                when existing stubs/ties/IDL are newer than the input class.
124
125              · The -factory option uses the factory keyword in generated IDL.
126
127              · The -idlModule from JavaPackage[.class]toIDLModule specifies
128                IDLEntity package mapping, for example: -idlModulemy.module
129                my::real::idlmod.
130
131              · -idlFilefromJavaPackage[.class] toIDLFile specifies IDLEntity
132                file mapping, for example: -idlFile test.pkg.X TEST16.idl.
133
134
135       -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
146              If you call the rmic command with the -iiop, then it generates
147              stubs and ties that conform to this naming convention:
148
149              _<implementationName>_stub.class
150              _<interfaceName>_tie.class
151
152
153              · When you use the -iiop option, other options also include:
154
155              · The -always or -alwaysgenerate options force regeneration even
156                when existing stubs/ties/IDL are newer than the input class.
157
158              · The -nolocalstubs option means do not create stubs optimized
159                for same-process clients and servers.
160
161              · 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
168              · 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
181
182              -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
187              -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
192              -nowarn
193                Turns off warnings. When the -nowarn options is used. The
194                compiler does not print out any warnings.
195
196              -nowrite
197                Does not write compiled classes to the file system.
198
199              -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
211              -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
216              -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
225              -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

ENVIRONMENT VARIABLES

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

SEE ALSO

240       · javac(1)
241
242       · java(1)
243
244       · Setting the Class Path
245
246
247
248JDK 8                          21 November 2013                        rmic(1)
Impressum