Le compilateur rmic

Paramètres

-iiop

Génère des classes stub et tie. Une classe stub est un proxy local pour un objet distant. Les clients utilisent des classes stub pour envoyer des appels à un serveur. Chaque interface distante nécessite une classe stub qui implémente cette interface distante. La référence d'objet distante utilisée par un client est une référence à un stub. Les classes tie sont utilisées sur le serveur pour traiter les appels entrants et envoyer les appels à la classe d'implémentation correcte. Chaque classe d'implémentation nécessite une classe tie.

Des classes stub sont également générées pour les interfaces abstraites. Une interface abstraite est une interface qui n'étend pas java.rmi.Remote, mais qui a des méthodes qui émettent une exception java.rmi.RemoteException ou une superclasse de java.rmi.RemoteException. Les interfaces qui n'étendent pas java.rmi.Remote et qui n'ont pas de méthodes sont également des interfaces abstraites.

-poa

Remplace l'héritage de org.omg.CORBA_2_3.portable.ObjectImpl par org.omg.PortableServer.Servant. Ce type de mappage n'est pas standard et n'est pas spécifié par la spécification Java Language to OMG IDL Mapping: https://www.omg.org/cgi-bin/doc?formal/01-06-07.

Le module PortableServer pour POA (Portable Object Adapter) définit le type Servant natif. Dans le langage de programmation Java, le type de serviteur est mappé à la classe Java org.omg.PortableServer.Servant . La classe sert de classe de base pour toutes les implémentations Serviteur POA. Elle fournit un nombre de méthodes qui peuvent être appelées par le programmeur de l'application, ainsi que des méthodes qui sont appelées par le POA et qui peuvent être remplacées par l'utilisateur pour contrôler des aspects du comportement du serviteur.

Valide uniquement lorsque l'option -iiop est présente.

-idl

Génère un IDL OMG pour les classes spécifiées et les classes référencées. Cette option est requise uniquement si vous disposez d'un client CORBA écrit dans un autre langage qui doit communiquer avec un serveur Java RMI-IIOP.

Astuce: Une fois que l'IDL OMG est généré à l'aide de rmic -idl, utilisez l'IDL généré avec un compilateur de langage IDL-vers-C++ ou autre, mais pas avec le compilateur de langage IDL-vers-Java. Le round tripping n'est pas recommandé et ne doit pas être nécessaire. La fonction de génération IDL est conçue pour être utilisée avec d'autres langages. Les clients ou les serveurs Java peuvent utiliser les types RMI-IIOP d'origine.

IDL fournit une méthode purement déclarative pour spécifier l'API d'un objet. IDL est indépendant du langage de programmation utilisé. L'IDL est utilisé comme spécification pour les méthodes et les données qui peuvent être écrites dans et appelées depuis un langage qui fournit des liaisons CORBA. Java et C++ sont de tels langages. Pour une description complète, voir la spécification Java Language to OMG IDL Mapping: https://www.omg.org/cgi-bin/doc?formal/01-06-07.

Restriction: L'IDL généré peut être compilé uniquement à l'aide d'un compilateur IDL qui prend en charge les extensions CORBA 2.3 à IDL.

-always

Force la régénération, même lorsque les stubs, les liens ou IDL sont plus récents que la classe d'entrée. Valide uniquement lorsque les options -iiop ou -idl sont présentes.

-noValueMethods

Vérifiez que les méthodes et les initialiseurs ne sont pas inclus dans les types de valeurs émis au cours de la génération IDL. Les méthodes et les initialiseurs sont facultatifs pour les types de valeurs et elles sont omises.

Valide uniquement avec l'option -idl.

-idlModule < fromJavaPackage [ .class ] > < toIDLModule>

Spécifie le mappage de package IDLEntity. Par exemple: -idlModule sample.bar my::real::idlmod.

Valide uniquement avec l'option -idl.

-idlFile < fromJavaPackage [ .class ] > < toIDLModule>

Spécifie le mappage de fichier IDLEntity. Par exemple: -idlFile test.pkg.X TEST16.idl.

Valide uniquement avec l'option -idl.