Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
rmic(1)		     Remote Method Invocation (RMI) Tools	       rmic(1)

       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)

       rmic [ options ]	package-qualified-class-names

	      The command-line options.	See Options.

	      Class names that include their packages, for example,

       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
       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

       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.

       -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:

       -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

	      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.

	      Enables the generation of	all debugging information, including
	      local variables. By default, only	line number information	is

	      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

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

	      o	The -always or -alwaysgenerate options force regeneration even
		when existing stubs/ties/IDL are newer than the	input class.

	      o	The -factory option uses the factory keyword in	generated IDL.

	      o	The -idlModule from JavaPackage[.class]toIDLModule specifies
		IDLEntity package mapping, for example:	-idlModulemy.module

	      o	-idlFilefromJavaPackage[.class]	toIDLFile specifies IDLEntity
		file mapping, for example: -idlFile test.pkg.X TEST16.idl.

	      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:


	      o	When you use the -iiop option, other options also include:

	      o	The -always or -alwaysgenerate options force regeneration even
		when existing stubs/ties/IDL are newer than the	input class.

	      o	The -nolocalstubs option means do not create stubs optimized
		for same-process clients and servers.

	      o	The -noValueMethods option must	be used	with the -idl option.
		The -noValueMethods option prevents the	addition of valuetype
		methods	and initializers to emitted IDL. These methods and
		initializers are optional for valuetypes, and are generated
		unless the -noValueMethods option is specified with the	-idl

	      o	The -poa option	changes	the inheritance	from
		org.omg.CORBA_2_3.portable.ObjectImpl to
		org.omg.PortableServer.Servant.	The PortableServer module for
		the Portable Object Adapter (POA) defines the native Servant
		type. In the Java programming language,	the Servant type is
		mapped to the Java org.omg.PortableServer.Servant class. It
		serves as the base class for all POA servant implementations
		and provides a number of methods that can be called by the
		application programmer,	and methods that are called by the POA
		and that can be	overridden by the user to control aspects of
		servant	behavior. Based	on the OMG IDL to Java Language
		Mapping	Specification, CORBA V 2.3.1 ptc/00-01-08.pdf..RE

		Used with any Java command, the	-J option passes the argument
		that follows the -J (no	spaces between the -Jand the argument)
		to the Java interpreter

	      -keep or -keepgenerated
		Retains	the generated .java source files for the stub,
		skeleton, and tie classes and writes them to the same
		directory as the.class files.

		Turns off warnings. When the -nowarn options is	used. The
		compiler does not print	out any	warnings.

		Does not write compiled	classes	to the file system.

	      -vcompat (deprecated)
		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. Note: This option has been
		deprecated. See	Description.

		Causes the compiler and	linker to print	out messages about
		what classes are being compiled	and what class files are being

	      -v1.1 (deprecated)
		Generates stub and skeleton classes for	the 1.1	JRMP stub
		protocol version only. The -v1.1 option	is only	useful for
		generating stub	classes	that are serialization-compatible with
		preexisting, statically	deployed stub classes that were
		generated by the rmic command from JDK 1.1 and that cannot be
		upgraded (and dynamic class loading is not being used).	Note:
		This option has	been deprecated. See Description.

	      -v1.2 (deprecated)
		(Default) Generates stub classes for the 1.2 JRMP stub
		protocol version only. No skeleton classes are generated
		because	skeleton classes are not used with the 1.2 stub
		protocol version. The generated	stub classes do	not work when
		they are loaded	into a JDK 1.1 virtual machine.	Note: This
		option has been	deprecated. See	Description.

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

       o javac(1)

       o java(1)

       o Setting the Class Path

JDK 8			       21 November 2013			       rmic(1)


Want to link to this manual page? Use this URL:

home | help