--- a/corba/src/java.corba/share/classes/org/omg/CORBA/doc-files/generatedfiles.html Wed Jul 05 20:49:25 2017 +0200
+++ b/corba/src/java.corba/share/classes/org/omg/CORBA/doc-files/generatedfiles.html Sun Sep 13 23:31:47 2015 +0300
@@ -9,7 +9,8 @@
<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>,
+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.
@@ -18,23 +19,25 @@
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 <tt>foo</tt> is mapped to the Java
-interfaces <tt>foo</tt> and <tt>fooOperations</tt>, and additional
-Java classes <tt>fooHelper</tt>, <tt>fooHolder</tt>, <tt>fooPOA</tt>,
-and optionally <tt>fooPOATie</tt>.
+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"><tt><type>Helper</tt></a>, where <tt><type></tt> is the name of an IDL defined type.
-<LI>The Java class <a href="#holder"><tt><type>Holder</tt></a>, where <tt><type></tt>
-is the name of an IDL defined type (with certain exceptions such as <tt>typedef</tt> aliases).
-<LI>The Java classes <tt><basicJavaType>Holder</tt>, where <tt><basicJavaType></tt>
+<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"><tt><interface>Operations</tt></a>, <tt><interface>POA</tt>,
-and <tt><interface>POATie</tt>, where <tt><interface></tt> is the name of an IDL interface type.
-<LI>The nested scope Java package name <tt><interface>Package</tt>, where <tt><interface></tt>
+<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>
@@ -42,50 +45,55 @@
<H2><a name="helper">Helper Files</a></H2>
<P>Helper files supply several static methods needed to manipulate the type.
-These include <tt>Any</tt> insert and extract operations for 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 <tt>org.omg.CORBA.Object</tt>
+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 <tt>CORBA::BAD_PARAM</tt> is thrown if the narrow fails because
+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.
+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 <tt>org.omg.CORBA</tt> package
+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, <tt>value</tt> which is the typed value. The default constructor
+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 <tt>org.omg.CORBA.portable.Streamable</tt> interface.
+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 <tt>IDLEntity</tt>, has the same
-name as the IDL interface name and is used as the signature type in method declarations
+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 <tt>Operations</tt>
+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 <tt>org.omg.CORBA.Object</tt>, as well as <tt>org.omg.portable.IDLEntity</tt>.
+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.
+expressed in IDL is reflected in both the Java signature
+interface and operations interface hierarchies.
<H2><a name="stub">Stubs</a></H2>
@@ -96,11 +104,13 @@
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
+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.
+<P>Object-oriented programming languages, such as Java,
+C++, and Smalltalk, do not require stub interfaces.
<BR><BR>