{
    "content": [
        {
            "type": "text",
            "text": "# rmic (man)\n\n## NAME\n\nrmic - 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)\n\n## SYNOPSIS\n\nrmic [ options ] package-qualified-class-names\noptions\nThe command-line options. See Options.\npackage-qualified-class-names\nClass names that include their packages, for example, java.awt.Color.\n\n## DESCRIPTION\n\nDeprecation Note: Support for static generation of Java Remote Method Protocol (JRMP) stubs\nand skeletons has been deprecated. Oracle recommends that you use dynamically generated JRMP\nstubs instead, eliminating the need to use this tool for JRMP-based applications. See the\njava.rmi.server.UnicastRemoteObject specification at\nhttp://docs.oracle.com/javase/8/docs/api/java/rmi/server/UnicastRemoteObject.html for further\ninformation.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION** (1 subsections)\n- **OPTIONS** (3 subsections)\n- **ENVIRONMENT VARIABLES**\n- **SEE ALSO**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n"
        }
    ],
    "structuredContent": {
        "command": "rmic",
        "section": "",
        "mode": "man",
        "summary": "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)",
        "synopsis": "rmic [ options ] package-qualified-class-names\noptions\nThe command-line options. See Options.\npackage-qualified-class-names\nClass names that include their packages, for example, java.awt.Color.",
        "tldr_summary": null,
        "tldr_examples": [],
        "tldr_source": null,
        "flags": [
            {
                "flag": "-g",
                "long": null,
                "arg": null,
                "description": "Enables the generation of all debugging information, including local variables. By default, only line number information is generated."
            },
            {
                "flag": "",
                "long": null,
                "arg": null,
                "description": "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 http://docs.oracle.com/javase/8/docs/technotes/guides/idl/mapping/jidlMapping.html When the -idl option is used, other options also include: • The -always or -alwaysgenerate options force regeneration even when existing stubs/ties/IDL are newer than the input class. • The -factory option uses the factory keyword in generated IDL. • The -idlModule from JavaPackage[.class]toIDLModule specifies IDLEntity package mapping, for example: -idlModulemy.module my::real::idlmod. • -idlFilefromJavaPackage[.class] toIDLFile specifies IDLEntity file mapping, for example: -idlFile test.pkg.X TEST16.idl."
            },
            {
                "flag": "",
                "long": null,
                "arg": null,
                "description": "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: <implementationName>stub.class <interfaceName>tie.class • When you use the -iiop option, other options also include: • The -always or -alwaysgenerate options force regeneration even when existing stubs/ties/IDL are newer than the input class. • The -nolocalstubs option means do not create stubs optimized for same-process clients and servers. • 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 option. • The -poa option changes the inheritance from org.omg.CORBA23.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 -J 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. -nowarn Turns off warnings. When the -nowarn options is used. The compiler does not print out any warnings. -nowrite 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. -verbose Causes the compiler and linker to print out messages about what classes are being compiled and what class files are being loaded. -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."
            }
        ],
        "examples": [],
        "see_also": [
            {
                "name": "javac",
                "section": "1",
                "url": "https://www.chedong.com/phpMan.php/man/javac/1/json"
            },
            {
                "name": "java",
                "section": "1",
                "url": "https://www.chedong.com/phpMan.php/man/java/1/json"
            }
        ],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 4,
                "subsections": []
            },
            {
                "name": "SYNOPSIS",
                "lines": 9,
                "subsections": []
            },
            {
                "name": "DESCRIPTION",
                "lines": 16,
                "subsections": [
                    {
                        "name": "rmic hello.HelloImpl",
                        "lines": 21
                    }
                ]
            },
            {
                "name": "OPTIONS",
                "lines": 29,
                "subsections": [
                    {
                        "name": "-g",
                        "lines": 3,
                        "flag": "-g"
                    },
                    {
                        "name": "-idl",
                        "lines": 21
                    },
                    {
                        "name": "-iiop",
                        "lines": 81
                    }
                ]
            },
            {
                "name": "ENVIRONMENT VARIABLES",
                "lines": 4,
                "subsections": []
            },
            {
                "name": "SEE ALSO",
                "lines": 9,
                "subsections": []
            }
        ],
        "sections": {
            "NAME": {
                "content": "rmic - Generates stub, skeleton, and tie classes for remote objects that use the Java Remote\nMethod Protocol (JRMP) or Internet Inter-Orb protocol (IIOP). Also generates Object\nManagement Group (OMG) Interface Definition Language (IDL)\n",
                "subsections": []
            },
            "SYNOPSIS": {
                "content": "rmic [ options ] package-qualified-class-names\n\n\noptions\nThe command-line options. See Options.\n\npackage-qualified-class-names\nClass names that include their packages, for example, java.awt.Color.\n",
                "subsections": []
            },
            "DESCRIPTION": {
                "content": "Deprecation Note: Support for static generation of Java Remote Method Protocol (JRMP) stubs\nand skeletons has been deprecated. Oracle recommends that you use dynamically generated JRMP\nstubs instead, eliminating the need to use this tool for JRMP-based applications. See the\njava.rmi.server.UnicastRemoteObject specification at\nhttp://docs.oracle.com/javase/8/docs/api/java/rmi/server/UnicastRemoteObject.html for further\ninformation.\n\nThe rmic compiler generates stub and skeleton class files using the Java Remote Method\nProtocol (JRMP) and stub and tie class files (IIOP protocol) for remote objects. These class\nfiles are generated from compiled Java programming language classes that are remote object\nimplementation classes. A remote implementation class is a class that implements the\ninterface java.rmi.Remote. The class names in the rmic command must be for classes that were\ncompiled successfully with the javac command and must be fully package qualified. For\nexample, running the rmic command on the class file name HelloImpl as shown here creates the\nHelloImplStub.classfile in the hello subdirectory (named for the class's package):\n",
                "subsections": [
                    {
                        "name": "rmic hello.HelloImpl",
                        "content": "A skeleton for a remote object is a JRMP protocol server-side entity that has a method that\ndispatches calls to the remote object implementation.\n\nA tie for a remote object is a server-side entity similar to a skeleton, but communicates\nwith the client with the IIOP protocol.\n\nA stub is a client-side proxy for a remote object that is responsible for communicating\nmethod invocations on remote objects to the server where the actual remote object\nimplementation resides. A client's reference to a remote object, therefore, is actually a\nreference to a local stub.\n\nBy default, the rmic command generates stub classes that use the 1.2 JRMP stub protocol\nversion only, as though the -v1.2 option was specified. The -vcompat option was the default\nin releases before 5.0. Use the -iiop option to generate stub and tie classes for the IIOP\nprotocol. See Options.\n\nA stub implements only the remote interfaces, and not any local interfaces that the remote\nobject also implements. Because a JRMP stub implements the same set of remote interfaces as\nthe remote object, a client can use the Java programming language built-in operators for\ncasting and type checking. For IIOP, the PortableRemoteObject.narrow method must be used.\n"
                    }
                ]
            },
            "OPTIONS": {
                "content": "-bootclasspath path\nOverrides the location of bootstrap class files.\n\n-classpath path\nSpecifies the path the rmic command uses to look up classes. This option overrides the\ndefault or the CLASSPATH environment variable when it is set. Directories are\nseparated by colons. The general format for path is: .:<yourpath>, for example:\n.:/usr/local/java/classes.\n\n-d directory\nSpecifies the root destination directory for the generated class hierarchy. You can\nuse this option to specify a destination directory for the stub, skeleton, and tie\nfiles. For example, the following command places the stub and skeleton classes derived\nfrom MyClass into the directory /java/classes/exampleclass.\n\nrmic -d /java/classes exampleclass.MyClass\n\n\n\nIf the -d option is not specified, then the default behavior is as if -d . was\nspecified. The package hierarchy of the target class is created in the current\ndirectory, and stub/tie/skeleton files are placed within it. In some earlier releases\nof the rmic command, if the -d option was not specified, then the package hierarchy\nwas not created, and all of the output files were placed directly in the current\ndirectory.\n\n-extdirs path\nOverrides the location of installed extensions.\n",
                "subsections": [
                    {
                        "name": "-g",
                        "content": "Enables the generation of all debugging information, including local variables. By\ndefault, only line number information is generated.\n",
                        "flag": "-g"
                    },
                    {
                        "name": "-idl",
                        "content": "Causes the rmic command to generate OMG IDL for the classes specified and any classes\nreferenced. IDL provides a purely declarative, programming language-independent way to\nspecify an API for an object. The IDL is used as a specification for methods and data\nthat can be written in and called from any language that provides CORBA bindings. This\nincludes Java and C++ among others. See Java IDL: IDL to Java Language Mapping at\nhttp://docs.oracle.com/javase/8/docs/technotes/guides/idl/mapping/jidlMapping.html\n\nWhen the -idl option is used, other options also include:\n\n• The -always or -alwaysgenerate options force regeneration even when existing\nstubs/ties/IDL are newer than the input class.\n\n• The -factory option uses the factory keyword in generated IDL.\n\n• The -idlModule from JavaPackage[.class]toIDLModule specifies IDLEntity package\nmapping, for example: -idlModulemy.module my::real::idlmod.\n\n• -idlFilefromJavaPackage[.class] toIDLFile specifies IDLEntity file mapping, for\nexample: -idlFile test.pkg.X TEST16.idl.\n\n"
                    },
                    {
                        "name": "-iiop",
                        "content": "Causes the rmic command to generate IIOP stub and tie classes, rather than JRMP stub\nand skeleton classes. A stub class is a local proxy for a remote object and is used by\nclients to send calls to a server. Each remote interface requires a stub class, which\nimplements that remote interface. A client reference to a remote object is a reference\nto a stub. Tie classes are used on the server side to process incoming calls, and\ndispatch the calls to the proper implementation class. Each implementation class\nrequires a tie class.\n\nIf you call the rmic command with the -iiop, then it generates stubs and ties that\nconform to this naming convention:\n\n<implementationName>stub.class\n<interfaceName>tie.class\n\n\n• When you use the -iiop option, other options also include:\n\n• The -always or -alwaysgenerate options force regeneration even when existing\nstubs/ties/IDL are newer than the input class.\n\n• The -nolocalstubs option means do not create stubs optimized for same-process\nclients and servers.\n\n• The -noValueMethods option must be used with the -idl option. The -noValueMethods\noption prevents the addition of valuetype methods and initializers to emitted IDL.\nThese methods and initializers are optional for valuetypes, and are generated unless\nthe -noValueMethods option is specified with the -idl option.\n\n• The -poa option changes the inheritance from org.omg.CORBA23.portable.ObjectImpl\nto org.omg.PortableServer.Servant. The PortableServer module for the Portable Object\nAdapter (POA) defines the native Servant type. In the Java programming language, the\nServant type is mapped to the Java org.omg.PortableServer.Servant class. It serves\nas the base class for all POA servant implementations and provides a number of\nmethods that can be called by the application programmer, and methods that are\ncalled by the POA and that can be overridden by the user to control aspects of\nservant behavior. Based on the OMG IDL to Java Language Mapping Specification, CORBA\nV 2.3.1 ptc/00-01-08.pdf..RE\n\n\n-J\nUsed with any Java command, the -J option passes the argument that follows the -J\n(no spaces between the -Jand the argument) to the Java interpreter\n\n-keep or -keepgenerated\nRetains the generated .java source files for the stub, skeleton, and tie classes and\nwrites them to the same directory as the.class files.\n\n-nowarn\nTurns off warnings. When the -nowarn options is used. The compiler does not print\nout any warnings.\n\n-nowrite\nDoes not write compiled classes to the file system.\n\n-vcompat (deprecated)\nGenerates stub and skeleton classes that are compatible with both the 1.1 and 1.2\nJRMP stub protocol versions. This option was the default in releases before 5.0. The\ngenerated stub classes use the 1.1 stub protocol version when loaded in a JDK 1.1\nvirtual machine and use the 1.2 stub protocol version when loaded into a 1.2 (or\nlater) virtual machine. The generated skeleton classes support both 1.1 and 1.2 stub\nprotocol versions. The generated classes are relatively large to support both modes\nof operation. Note: This option has been deprecated. See Description.\n\n-verbose\nCauses the compiler and linker to print out messages about what classes are being\ncompiled and what class files are being loaded.\n\n-v1.1 (deprecated)\nGenerates stub and skeleton classes for the 1.1 JRMP stub protocol version only. The\n-v1.1 option is only useful for generating stub classes that are serialization-\ncompatible with preexisting, statically deployed stub classes that were generated by\nthe rmic command from JDK 1.1 and that cannot be upgraded (and dynamic class loading\nis not being used). Note: This option has been deprecated. See Description.\n\n-v1.2 (deprecated)\n(Default) Generates stub classes for the 1.2 JRMP stub protocol version only. No\nskeleton classes are generated because skeleton classes are not used with the 1.2\nstub protocol version. The generated stub classes do not work when they are loaded\ninto a JDK 1.1 virtual machine. Note: This option has been deprecated. See\nDescription.\n"
                    }
                ]
            },
            "ENVIRONMENT VARIABLES": {
                "content": "CLASSPATH\nUsed to provide the system a path to user-defined classes. Directories are separated\nby colons, for example: .:/usr/local/java/classes.\n",
                "subsections": []
            },
            "SEE ALSO": {
                "content": "• javac(1)\n\n• java(1)\n\n• Setting the Class Path\n\n\n\nJDK 8                                     21 November 2013                                   rmic(1)",
                "subsections": []
            }
        }
    }
}