1rmic(1) General Commands Manual rmic(1)
2
6 rmic - The Java RMI Compiler
7 rmic generates stub, skeleton, and tie classes for remote objects using
9 either the JRMP or IIOP protocols. Also generates OMG IDL.
10
12 rmic [ options ] package-qualified-class-name(s)
13
16 The rmic compiler generates stub and skeleton class files (JRMP proto‐
17 col) and stub and tie class files (IIOP protocol) for remote objects.
18 These classes files are generated from compiled Java programming lan‐
19 guage classes that are remote object implementation classes. A remote
20 implementation class is a class that implements the interface
21 java.rmi.Remote. The class names in the rmic command must be for
22 classes that have been compiled successfully with the javac command and
23 must be fully package qualified. For example, running rmic on the class
24 file name HelloImpl as shown here:
25 rmic hello.HelloImpl
27 creates the HelloImpl_Stub.class file in the hello subdirectory (named
30 for the class's package).
31 A skeleton for a remote object is a JRMP protocol server-side entity
33 that has a method that dispatches calls to the actual remote object
34 implementation.
35 A tie for a remote object is a server-side entity similar to a skele‐
37 ton, but which communicates with the client using the IIOP protocol.
38 A stub is a client-side proxy for a remote object which is responsible
40 for communicating method invocations on remote objects to the server
41 where the actual remote object implementation resides. A client's ref‐
42 erence to a remote object, therefore, is actually a reference to a
43 local stub.
44 By default, rmic generates stub classes that use the 1.2 JRMP stub pro‐
46 tocol version only, as if the -v1.2 option had been specified. (Note
47 that the -vcompat option was the default in releases prior to 5.0.) Use
48 the -iiop option to generate stub and tie classes for the IIOP proto‐
49 col.
50 A stub implements only the remote interfaces, not any local interfaces
52 that the remote object also implements. Because a JRMP stub implements
53 the same set of remote interfaces as the remote object itself, a client
54 can use the Java programming language's built-in operators for casting
55 and type checking. For IIOP, the PortableRemoteObject.narrow method
56 must be used.
57
59 -bootclasspath path
60 Overrides location of bootstrap class files
61 -classpath path
63 Specifies the path rmic uses to look up classes. This option over‐
64 rides the default or the CLASSPATH environment variable if it is
65 set. Directories are separated by colons. Thus the general format
66 for path is:
67 For example:
70 -d directory
73 Specifies the root destination directory for the generated class
74 hierarchy. You can use this option to specify a destination direc‐
75 tory for the stub, skeleton, and tie files. For example, the command
76 % rmic -d /java/classes foo.MyClass
79 would place the stub and skeleton classes derived from MyClass into the
80 directory /java/classes/foo. If the -d option is not specified, the
81 default behavior is as if "-d ." were specified: the package hierarchy
82 of the target class is created in the current directory, and
83 stub/tie/skeleton files are placed within it. (Note that in some previ‐
84 ous versions of rmic, if -d was not specified, then the package hierar‐
85 chy was not created, and all of the output files were placed directly
86 in the current directory.)
87 -extdirs path
90 Overrides location of installed extensions
91 -g Enables generation of all debugging information, including local
93 variables. By default, only line number information is generated.
94 -idl
96 Causes rmic to generate OMG IDL for the classes specified and any
97 classes referenced. IDL provides a purely declarative, programming
98 language-independent way of specifying an object's API. The IDL is
99 used as a specification for methods and data that can be written in
100 and invoked from any language that provides CORBA bindings. This
101 includes Java and C++ among others. See the Java Language to IDL
102 Mapping @
103 http://www.omg.org/technology/documents/formal/java_language_map‐
104 ping_to_omg_idl.htm (OMG) document for a complete description.
105 When the -idl option is used, other options also include:
107 -always or -alwaysgenerate
109 Forces re-generation even when existing stubs/ties/IDL are newer
110 than the input class.
111 -factory
113 Uses factory keyword in generated IDL.
114 -idlModule fromJavaPackage[.class]
116 toIDLModule Specifies IDLEntity package mapping. For example:
117 -idlModule foo.bar my::real::idlmod.
118 -idlFile fromJavaPackage[.class]
120 toIDLFile Specifies IDLEntity file mapping. For example: -idlFile
121 test.pkg.X TEST16.idl.
122 -iiop
124 Causes rmic to generate IIOP stub and tie classes, rather than JRMP
125 stub and skeleton classes. A stub class is a local proxy for a
126 remote object and is used by clients to send calls to a server. Each
127 remote interface requires a stub class, which implements that remote
128 interface. A client's reference to a remote object is actually a
129 reference to a stub. Tie classes are used on the server side to
130 process incoming calls, and dispatch the calls to the proper imple‐
131 mentation class. Each implementation class requires a tie class.
132 Invoking rmic with the -iiop generates stubs and ties that conform to
134 this naming convention:
135 _<implementationName>_stub.class
138 _<interfaceName>_tie.class
139 When the -iiop option is used, other options also include:
141 -always or -alwaysgenerate
143 Forces re-generation even when existing stubs/ties/IDL are newer
144 than the input class.
145 -nolocalstubs
147 Do not create stubs optimized for same-process clients and servers.
148 -noValueMethods
150 Must be used with the -idl option. Prevents addition of valuetype
151 methods and initializers to emitted IDL. These methods and initial‐
152 izers are optional for valuetypes, and are generated unless the
153 -noValueMethods option is specified when using the -idl option.
154 -poa
156 Changes the inheritance from org.omg.CORBA_2_3.portable.ObjectImpl
157 to org.omg.PortableServer.Servant.
158 The PortableServer module for the Portable Object Adapter @
160 http://java.sun.com/javase/6/docs/technotes/guides/idl/POA.html (POA)
161 defines the native Servant type. In the Java programming language, the
162 Servant type is mapped to the Java org.omg.PortableServer.Servant
163 class. It serves as the base class for all POA servant implementations
164 and provides a number of methods that may be invoked by the application
165 programmer, as well as methods which are invoked by the POA itself and
166 may be overridden by the user to control aspects of servant behavior.
167 Based on the OMG IDL to Java Language Mapping Specification, CORBA V
168 2.3.1 ptc/00-01-08.pdf.
169 -J Used in conjunction with any java option, it passes the option fol‐
171 lowing the -J (no spaces between the -J and the option) on to the
172 java interpreter.
173 -keep or -keepgenerated
175 Retains the generated .java source files for the stub, skeleton,
176 and/or tie classes and writes them to the same directory as the
177 .class files.
178 -nowarn
180 Turns off warnings. If used the compiler does not print out any
181 warnings.
182 -vcompat
184 Generates stub and skeleton classes compatible with both the 1.1 and
185 1.2 JRMP stub protocol versions. (This option was the default in
186 releases prior to 5.0.) The generated stub classes will use the 1.1
187 stub protocol version when loaded in a JDK 1.1 virtual machine and
188 will use the 1.2 stub protocol version when loaded into a 1.2 (or
189 later) virtual machine. The generated skeleton classes will support
190 both 1.1 and 1.2 stub protocol versions. The generated classes are
191 relatively large in order to support both modes of operation.
192 -verbose
194 Causes the compiler and linker to print out messages about what
195 classes are being compiled and what class files are being loaded.
196 -v1.1
198 Generates stub and skeleton classes for the 1.1 JRMP stub protocol
199 version only. Note that this option is only useful for generating
200 stub classes that are serialization-compatible with pre-existing,
201 statically-deployed stub classes that were generated by the rmic
202 tool from JDK 1.1 and that cannot be upgraded (and dynamic class
203 loading is not being used).
204 -v1.2
206 (default) Generates stub classes for the 1.2 JRMP stub protocol ver‐
207 sion only. No skeleton classes are generated with this option
208 because skeleton classes are not used with the 1.2 stub protocol
209 version. The generated stub classes will not work if they are loaded
210 into a JDK 1.1 virtual machine.
211
213 CLASSPATH
214 Used to provide the system a path to user-defined classes. Directo‐
215 ries are separated by colons. For example,
216
219 java, javac, CLASSPATH
220 05 Aug 2006 rmic(1)