| <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html"> |
| <title>IDL-to-Java Generated Files</title> |
| </head> |
| <body bgcolor="#FFFFFF"> |
| |
| <H1>IDL-to-Java Generated Files</H1> |
| |
| <P>The files that are generated by the IDL-to-Java compiler, in accordance with |
| the <em><a href="http://www.omg.org/cgi-bin/doc?ptc/00-01-08"> |
| IDL-to-Java Language Mapping Specification</a></em>, |
| which is implemented in Java<sup><font size="-2">TM</font></sup> SE 6 |
| according the <a href="compliance.html">compliance</a> document. |
| |
| |
| <P>In general IDL names and identifiers are mapped to Java names |
| and identifiers with no change. Because of the nature of the Java language, |
| a single IDL construct may be mapped to several (differently named) Java constructs. |
| The additional names are constructed by appending a descriptive suffix. |
| For example, the IDL interface <code>foo</code> is mapped to the Java |
| interfaces <code>foo</code> and <code>fooOperations</code>, and additional |
| Java classes <code>fooHelper</code>, <code>fooHolder</code>, <code>fooPOA</code>, |
| and optionally <code>fooPOATie</code>. |
| |
| |
| |
| <P>The mapping in effect reserves the use of several names for its own purposes. These are: |
| <UL> |
| <LI>The Java class <a href="#helper"><code><type>Helper</code></a>, |
| where <code><type></code> is the name of an IDL defined type. |
| <LI>The Java class <a href="#holder"><code><type>Holder</code></a>, |
| where <code><type></code> |
| is the name of an IDL defined type (with certain exceptions such as <code>typedef</code> aliases). |
| <LI>The Java classes <code><basicJavaType>Holder</code>, where <code><basicJavaType></code> |
| is one of the Java primitive datatypes that is used by one of the IDL basic datatypes. |
| <LI>The Java classes <a href="#operations"><code><interface>Operations</code></a>, <code><interface>POA</code>, |
| and <code><interface>POATie</code>, where <code><interface></code> is the name of an IDL interface type. |
| <LI>The nested scope Java package name <code><interface>Package</code>, where <code><interface></code> |
| is the name of an IDL interface. |
| </UL> |
| |
| |
| <H2><a name="helper">Helper Files</a></H2> |
| |
| <P>Helper files supply several static methods needed to manipulate the type. |
| These include <code>Any</code> insert and extract operations for the type, |
| getting the repository id, getting the typecode, and reading |
| and writing the type from and to a stream. |
| |
| <P>The helper class for a mapped IDL interface or abstract interface also |
| include narrow operation(s). The static narrow method allows an <code>org.omg.CORBA.Object</code> |
| to be narrowed to the object reference of a more specific type. |
| The IDL exception <code>CORBA::BAD_PARAM</code> is thrown if the narrow fails because |
| the object reference does not support the requested type. A different system exception |
| is raised to indicate other kinds of errors. Trying to narrow |
| a null will always succeed with a return value of null. |
| |
| <H2><a name="holder">Holder Files</a></H2> |
| |
| <P>Support for out and inout parameter passing modes requires the use of additional holder classes. |
| These classes are available for all of the basic IDL datatypes in the <code>org.omg.CORBA</code> package |
| and are generated for all named user defined IDL types except those defined by typedefs. |
| (Note that in this context user defined includes types that are defined in OMG specifications |
| such as those for the Interface Repository, and other OMG services.) |
| |
| <P>Each holder class has a constructor from an instance, a default constructor, and has |
| a public instance member, <code>value</code> which is the typed value. The default constructor |
| sets the value field to the default value for the type as defined by the Java language: |
| false for boolean, 0 for numeric and char types, null for strings, null for object references. |
| |
| <P>To support portable stubs and skeletons, holder classes also implement |
| the <code>org.omg.CORBA.portable.Streamable</code> interface. |
| |
| |
| <H2><a name="operations">Operations Files</a></H2> |
| |
| <P>A non abstract IDL interface is mapped to two public Java interfaces: |
| a <em>signature</em> interface and an <em>operations</em> interface. |
| The signature interface, which extends <code>IDLEntity</code>, has the same |
| name as the IDL interface name and is used |
| as the signature type in method declarations |
| when interfaces of the specified type are used in other interfaces. |
| The operations interface has the same name as the IDL interface |
| with the suffix <code>Operations</code> |
| appended to the end and is used in the server-side mapping and as a mechanism |
| for providing optimized calls for collocated client and servers. |
| |
| <P>The Java operations interface contains the mapped operation signatures. |
| The Java signature interface extends the operations interface, |
| the (mapped) base <code>org.omg.CORBA.Object</code>, |
| as well as <code>org.omg.portable.IDLEntity</code>. |
| Methods can be invoked on the signature interface. Interface inheritance |
| expressed in IDL is reflected in both the Java signature |
| interface and operations interface hierarchies. |
| |
| |
| <H2><a name="stub">Stubs</a></H2> |
| |
| <P>For the mapping of a non-object-oriented language, there will be |
| a programming interface to the stubs for each interface type. Generally, the stubs |
| will present access to the OMG IDL-defined operations on an object in a way that is easy |
| for programmers to predict once they are familiar with OMG IDL and the language mapping |
| for the particular programming language. The stubs make calls on the rest of the ORB |
| using interfaces that are private to, and presumably optimized for, the particular ORB Core. |
| If more than one ORB is available, there may be different stubs |
| corresponding to the different ORBs. In this case, it is necessary for |
| the ORB and language mapping to cooperate to associate |
| the correct stubs with the particular object reference. |
| |
| <P>Object-oriented programming languages, such as Java, |
| C++, and Smalltalk, do not require stub interfaces. |
| |
| <BR><BR> |
| |
| </body> |
| </html> |