< prev index next >

src/java.corba/share/classes/org/omg/CORBA/package.html

Print this page




  17 *
  18 * This code is distributed in the hope that it will be useful, but WITHOUT
  19 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  20 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  21 * version 2 for more details (a copy is included in the LICENSE file that
  22 * accompanied this code).
  23 *
  24 * You should have received a copy of the GNU General Public License version
  25 * 2 along with this work; if not, write to the Free Software Foundation,
  26 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  27 *
  28 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  29 * or visit www.oracle.com if you need additional information or have any
  30 * questions.
  31 */  
  32 -->
  33 </HEAD>
  34 <BODY BGCOLOR="#FFFFFF">
  35 Provides the mapping of the OMG CORBA APIs to the Java<SUP><FONT 
  36 SIZE=-2>TM</FONT></SUP>
  37 programming language, including the class <TT>ORB</TT>, which is implemented
  38 so that a programmer can use it as a fully-functional Object Request Broker
  39 (ORB).
  40 
  41 <P>For a precise list of supported sections of official CORBA specifications with which 
  42 the Java[TM] Platform, Standard Edition 6 complies, see <A 
  43 HREF="doc-files/compliance.html"><em>Official Specifications for CORBA support in 
  44 Java[TM] SE 6</em></A>.
  45 
  46 
  47 <H1>General Information</H1>
  48 The information in this section is information relevant to someone who 
  49 compiles Interface Definition Language (IDL) files and uses the
  50 ORB to write clients and servers.
  51 
  52 <P>The classes and interfaces described in this section can be put into 
  53 four groups: <tt>ORB classes</tt>, Exceptions, <tt>Helper</tt> classes,
  54 and <tt>Holder</tt> classes.
  55 
  56 <H2>
  57 The <tt>ORB</tt> Class</H2>
  58 
  59 <P>An ORB handles (or brokers) method invocations between a client and
  60 the method's implementation on a server. Because the client and server
  61 may be anywhere on a network, and because the invocation and implementation
  62 may be written in different programming languages, an ORB does a great
  63 deal of work behind the scenes to accomplish this communication.
  64 
  65 <P>Most of what an ORB does is completely transparent to the user, and a major
  66 portion of the <TT>CORBA</TT> package consists of classes used by the ORB
  67 behind the scenes. The result is that most programmers will use only a
  68 small part of this package directly. In fact, most programmers will use
  69 only a few methods from the <TT>ORB</TT> class, some exceptions, and 
  70 occasionally,
  71 a holder class. 
  72 <H3>
  73 <TT>ORB</TT> Methods</H3>
  74 
  75 <P>Before an application can enter the CORBA environment, it must first: 
  76 <UL>
  77 <LI>Be initialized into the ORB and possibly the object adapter (POA) environments.
  78 <LI>Get references to ORB object (for use in future ORB operations) 
  79 and perhaps other objects (including the root POA or some Object Adapter objects). 
  80 </UL>
  81 <P>The following operations are provided to initialize applications and obtain
  82  the appropriate object references:
  83  <UL>
  84  <LI>Operations providing access to the ORB, which are discussed in this
  85  section.
  86  <LI>Operations providing access to Object Adapters, Interface Repository, 
  87  Naming Service, and other Object Services. These operations are described 
  88  in <a href="#adv"><em>Other Classes</em></a>.
  89  </UL>
  90  <P>
  91 When an application requires a CORBA environment it needs a mechanism to 
  92 get an ORB object reference and possibly an OA object reference 
  93 (such as the root POA). This serves two purposes. First, it initializes 
  94 an application into the ORB and OA environments. Second, it returns the 
  95 ORB object reference and the OA object reference to the application 
  96 for use in future ORB and OA operations. 
  97 
  98 <P>In order to obtain an ORB object reference, applications call 
  99 the <tt>ORB.init</tt> operation. The parameters to the call can comprise an 
 100 identifier for the ORB for which the object reference is required,
 101  and an arg_list, which is used to allow environment-specific data to be 
 102  passed into the call. 
 103 
 104 <P>These are the <TT>ORB</TT> methods
 105  that provide access to the ORB:
 106 <UL>
 107 <LI>
 108 <TT><b>init</b>()</TT>
 109 
 110 <LI>
 111 <TT><b>init</b>(String [] args, Properties props)</TT>
 112 
 113 <LI>
 114 <TT><b>init</b>(Applet app, Properties props)</TT>
 115 </UL>
 116 
 117 <P>Using the <tt>init()</tt> method without parameters initiates 
 118 a singleton ORB,  which can only
 119 give typecode creation <tt>any</tt>s needed in code generated
 120 in Helper classes by <tt>idlj</tt>.
 121 
 122 <P>Applications require a portable means by which to obtain their 
 123 initial object references. References are required for the root 
 124 POA, POA Current, Interface Repository, and various Object Services 
 125 instances.  The functionality required by the application is similar
 126  to that provided by the Naming Service. However, the OMG does not 
 127  want to mandate that the Naming Service be made available to all 
 128  applications in order that they may be portably initialized. 
 129  Consequently, the operations shown in this section provide a 
 130  simplified, local version of the Naming Service that applications 
 131  can use to obtain a small, defined set of object references which 
 132  are essential to its operation. Because only a small well-defined 
 133  set of objects are expected with this mechanism, the naming context
 134  can be flattened to be a single-level name space. This simplification
 135  results in only two operations being defined to achieve the functionality
 136   required.
 137   
 138 <P>Initial references are obtained via two operations provided in 
 139 the ORB object interface, providing facilities to list and 
 140 resolve initial object references.  These are:
 141 <UL>
 142 <LI>
 143 <TT><b>resolve_initial_references</b>(String name)</TT>
 144 <LI>
 145 <TT><b>list_initial_services</b>()</TT>
 146 <LI>
 147 <TT><b>register_initial_reference</b>(String id, 
 148 org.omg.CORBA.Object obj)</TT>
 149 </UL>
 150 
 151 <P>An example that uses some of these methods is <A 
 152 HREF="{@docRoot}/../technotes/guides/idl/GShome.html">
 153 <em>Getting Started with Java IDL</em></A>.
 154 
 155 <H2>
 156 Exceptions</H2>
 157 Exceptions in Java IDL are similar to those in any code written in the
 158 Java programming language. If a method is defined to throw an exception,
 159 then any code using that method must have a <TT>try</TT>/<TT>catch</TT>
 160 block and handle that exception when it is thrown.
 161 
 162 <P>The documentation on <A 
 163 HREF="{@docRoot}/../technotes/guides/idl/jidlExceptions.html"><em>Java
 164 IDL exceptions</em></A> has more information and explains the difference between
 165 system exceptions and user-defined exceptions.
 166 
 167 <P>The following is a list of the system exceptions (which are unchecked
 168 exceptions inheriting through <TT><a href="SystemException.html">
 169 org.omg.CORBA.SystemException</a></TT> from
 170 <TT>java.lang.RuntimeException</TT>) that are defined in the package 
 171 <TT>org.omg.CORBA</TT>:
 172 <PRE><code>
 173 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BAD_CONTEXT
 174 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BAD_INV_ORDER
 175 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BAD_OPERATION
 176 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BAD_PARAM
 177 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BAD_TYPECODE
 178 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; COMM_FAILURE
 179 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DATA_CONVERSION
 180 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FREE_MEM
 181 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMP_LIMIT
 182 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INITIALIZE
 183 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTERNAL
 184 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTF_REPOS
 185 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INVALID_TRANSACTION
 186 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INV_FLAG
 187 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INV_IDENT
 188 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INV_OBJREF
 189 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INV_POLICY
 190 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MARSHAL
 191 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="#NO_IMPLEMENT">NO_IMPLEMENT</a>
 192 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO_MEMORY
 193 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO_PERMISSION
 194 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO_RESOURCES
 195 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO_RESPONSE
 196 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT_NOT_EXIST
 197 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJ_ADAPTER
 198 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PERSIST_STORE
 199 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TRANSACTION_REQUIRED
 200 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TRANSACTION_ROLLEDBACK
 201 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TRANSIENT
 202 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UNKNOWN
 203 </code></PRE>
 204 <P>
 205 The following is a list of user-defined exceptions defined in the package
 206 <TT>org.omg.CORBA</TT>.
 207 <PRE><code>
 208 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bounds
 209 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UnknownUserException
 210 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WrongTransaction&nbsp;
 211 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PolicyError
 212 </code></PRE>
 213 
 214  <H2>Subpackages</H2>
 215 There are some packages inside the <TT>CORBA</TT> package with
 216 "Package" as part of their names. These packages are generally quite small
 217 because all they do is provide exceptions or classes for use by interfaces
 218 and classes in the <TT>CORBA</TT> package.
 219 
 220 <P>For example, the package <TT><a href="TypeCodePackage/package-summary.html">
 221 org.omg.CORBA.TypeCodePackage</a></TT> contains
 222 two exceptions thrown by methods in the class <TT>TypeCode</TT>. These
 223 exceptions are:
 224 <UL>
 225 <LI>
 226 <TT>BadKind</TT>
 227 
 228 <LI>
 229 <TT>Bounds</TT>
 230 </UL>
 231 The package <TT><a href="ORBPackage/package-summary.html">
 232 org.omg.CORBA.ORBPackage</a></TT> contains two exceptions:
 233 <UL>
 234 <LI>
 235 <TT>InvalidName</TT>
 236 
 237 <LI>
 238 <TT>InconsistentTypeCode</TT>
 239 </UL>
 240 
 241 <P>Another package that is a subpackage of <tt>CORBA</tt> is the <tt>
 242 <a href="portable/package-summary.html">portable</a></tt> package.  It 
 243 provides a set of ORB APIs that makes it 
 244 possible for code generated by one vendor's IDL compiler to run
 245 on another vendor's ORB. 
 246 
 247 
 248 
 249 
 250 <H2>
 251 Holder classes</H2>
 252  
 253 
 254 <P>Support for out and inout parameter passing modes requires the use of 
 255 additional  <em><a href="doc-files/generatedfiles.html#holder">holder  
 256 classes</a></em>. Because the Java programming language does not support out or 
 257 inout parameters, holder classes are needed as a means of passing a parameter
 258 that can be modified.   To support portable stubs and skeletons, holder classes also implement
 259  the <tt><a href="portable/Streamable.html">org.omg.CORBA.portable.Streamable</a>
 260  </tt> interface.

 261  
 262  <P>Holder classes are named by appending "Holder" to the name of the type.
 263  The name of the type refers to its name in the Java programming language.  For
 264  example, a holder class for the interface named <tt>Account</tt> in the Java programming
 265  language would be named <tt>AccountHolder</tt>.

 266 
 267 
 268 <P>Holder classes are available for all of the basic IDL
 269  datatypes in the <tt>org.omg.CORBA</tt> package.  So, for example, 
 270   there are already-defined classes for <tt>LongHolder</tt>, <tt>ShortHolder</tt>,
 271  <tt>FloatHolder</tt>, and so on.  Classes are also generated for 
 272  all named user-defined IDL types except those defined by <tt>typedefs</tt>. 
 273  (Note that in this context user defined includes types that are 
 274  defined in OMG specifications such as those for the Interface
 275   Repository, and other OMG services.) 
 276 
 277 
 278 <P>Each holder class has:
 279 <UL>
 280 <LI>a constructor from an instance
 281 <LI>a default constructor
 282 <LI>a public instance member, <tt>value</tt> which is the typed value. 
 283 <LI>a method for reading an input stream and assigning the contents to the 
 284 type's <tt>value</tt> field
 285 <LI>a method for writing the value of the <tt>value</tt> field to an output stream
 286 <LI>a method for getting the typecode of the type
 287 </UL>
 288 
 289 <P>The default constructor sets the value field to the default value for the 
 290 type as defined by the Java language: 
 291 <UL>
 292 <LI><tt>false</tt> for boolean
 293 <LI><tt>0</tt> for numeric and char types
 294 <LI><tt>null</tt> for strings and object references
 295 </UL>
 296 
 297 
 298 
 299 <P>
 300 As an example, if the interface <code>Account</code>, defined in OMG IDL,
 301 were mapped to the Java programming language, the following holder class
 302 would be generated:
 303 <PRE>
 304 public final class AccountHolder implements 
 305     org.omg.CORBA.portable.Streamable
 306 {
 307   // field that holds an Account object
 308   public Account value = null;
 309 
 310   // default constructor
 311   public AccountHolder ()
 312   {
 313   }
 314   


 325   }
 326 
 327   // writes value to o
 328   public void _write (org.omg.CORBA.portable.OutputStream o)
 329   {
 330     AccountHelper.write (o, value);
 331   }
 332  
 333   // returns the typecode for Account
 334   public org.omg.CORBA.TypeCode _type ()
 335   {
 336     return AccountHelper.type ();
 337   }
 338 
 339 }
 340 </PRE>
 341 
 342 <P>For more information on Holder classes, see Chapter 1.4, <em>Mapping for
 343 Basic Types</em> in the <a href="http://www.omg.org/cgi-bin/doc?ptc/00-01-08">
 344 <em>OMG IDL to Java Language Mapping</em></a>. The Holder classes defined 
 345 in the package <TT>org.omg.CORBA</TT> are:
 346 <PRE>
 347 &nbsp;&nbsp;&nbsp;&nbsp; <TT>AnyHolder
 348 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>AnySeqHolder
 349 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>BooleanHolder
 350 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>BooleanSeqHolder
 351 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ByteHolder
 352 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>CharHolder
 353 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>CharSeqHolder
 354 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>CurrentHolder
 355 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>DoubleHolder
 356 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>DoubleSeqHolder
 357 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>FixedHolder
 358 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>FloatHolder
 359 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>FloatSeqHolder
 360 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>IntHolder
 361 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>LongHolder
 362 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>LongLongSeqHolder
 363 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>LongSeqHolder
 364 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ObjectHolder
 365 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>OctetSeqHolder
 366 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ParameterModeHolder
 367 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>PolicyErrorHolder
 368 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>PolicyListHolder
 369 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>PrincipalHolder
 370 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ServiceInformationHolder
 371 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ShortHolder
 372 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ShortSeqHolder
 373 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>StringHolder
 374 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>StringSeqHolder
 375 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>TypeCodeHolder
 376 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ULongLongSeqHolder
 377 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ULongSeqHolder
 378 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>UnknownUserExceptionHolder
 379 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>UShortSeqHolder
 380 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ValueBaseHolder
 381 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>WCharSeqHolder
 382 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>WrongTransactionHolder
 383 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>WStringSeqHolder</TT>
 384 
 385 </PRE>
 386 
 387 <h2>Helper Classes </h2>
 388 <P>Helper files supply several static methods needed to manipulate the type.
 389  These include:
 390  <UL>
 391  <LI><tt>Any</tt> insert and extract operations for the type
 392  <LI>getting the repository id
 393  <LI>getting the typecode
 394  <LI>reading and writing the type from and to a stream
 395  <LI>implement the <code>ValueHelper</code> interface (if it is  a user-defined
 396    value type)
 397  </UL> 
 398 
 399 <P>The helper class for a mapped IDL interface or abstract interface
 400  also include narrow operation(s). The static narrow method allows 
 401  an <tt>org.omg.CORBA.Object</tt> to be narrowed to the object reference 
 402  of a more specific type. The IDL exception <tt>CORBA.BAD_PARAM</tt> 
 403  is thrown if the narrow fails because the object reference does not 
 404  support the requested type. A different system exception is raised 
 405  to indicate other kinds of errors. Trying to narrow a <tt>null</tt> will always
 406   succeed with a return value of <tt>null</tt>. Generally, the only helper method an application programmer uses is

 407 the <code>narrow</code> method.  The other methods are normally used behind
 408 the scenes and are transparent to the programmer.
 409 
 410 <P>Helper classes
 411 fall into two broad categories, <a href="#value">helpers for value types</a> and
 412 <a href="#basic">helpers for non value types</a>. Because all of the helper 
 413 classes in one category
 414 provide the same methods, one generic explanation of each 
 415 category of helper classes is presented here.
 416 
 417 <P>
 418 When OMG IDL is mapped to the Java programming language, 
 419 a "helper" class is generated for each user-defined type.
 420 This generated class will have the name of the user-defined type with
 421 the suffix <code>Helper</code> appended.  For example, if the
 422 interface <code>Account</code> is defined in OMG IDL, the
 423 <code>idlj</code> compiler will automatically generate a class named
 424 <code>AccountHelper</code>.  The <code>AccountHelper</code> class
 425 will contain the static methods needed for manipulating instances of the type,
 426 in this case, <code>Account</code> objects. 
 427 
 428 
 429 <a name="narrow"></a>
 430 <h3>The <code>narrow</code> Method</h3>
 431 When an object is the return value for a method, it is returned in the
 432 form of a generic object, either an <code>org.omg.CORBA.Object</code> object
 433 or a <code>java.lang.Object</code> object. This object must be cast to its
 434 more specific type before it can be operated on.  For example, an
 435 <code>Account</code> object will be returned as a generic object and must
 436 be narrowed to an <code>Account</code> object so that <code>Account</code>
 437 methods may be called on it.
 438 <P>
 439 The <code>narrow</code> method has two forms, one that takes an
 440 <code>org.omg.CORBA.Object</code> object and one that takes a
 441 <code>java.lang.Object</code> object. Whether the interface is abstract or
 442 not determines which <code>narrow</code> method its helper class will provide.
 443 The helper class for an interface
 444 that is not abstract will have a <code>narrow</code> method that takes a CORBA
 445 object, whereas the <code>narrow</code> method for an interface that is abstract 
 446 will
 447 take an object in the Java programming language.  The helper class for a
 448 non-abstract interface that has at least one abstract base interface will provide
 449 both versions of the <code>narrow</code> method.
 450 <P>The <A HREF="{@docRoot}/../technotes/guides/idl/jidlExample.html"><em>Hello World</em></A> 
 451 tutorial uses a <tt>narrow</tt> method that looks 
 452 like this:
 453 <PRE>
 454         // create and initialize the ORB
 455         ORB orb = ORB.init(args, null);
 456 
 457         // get the root naming context
 458         org.omg.CORBA.Object objRef = 
 459             orb.resolve_initial_references("NameService");
 460         // Use NamingContextExt instead of NamingContext. This is 
 461         // part of latest Inter-Operable naming Service.  
 462         NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
 463  
 464         // resolve the Object Reference in Naming
 465         String name = "Hello";
 466         helloImpl = HelloHelper.narrow(ncRef.resolve_str(name));
 467 </PRE>
 468 
 469 <a name="basic"></a>
 470 <h3>Example of a Basic Helper Class</h3>
 471 A basic helper class, for purposes of this explanation, is one with
 472 the methods that are provided by every helper class, plus a <code>narrow</code> 


 609   {
 610     return _id;
 611   }
 612 
 613   // reads a serializable instance of Address from the given input stream
 614   public static Address read (org.omg.CORBA.portable.InputStream istream)
 615   {
 616     return (Address)((org.omg.CORBA_2_3.portable.InputStream) istream).read_value (id ());
 617   }
 618 
 619   // writes a serializable instance of Address to the given output stream
 620   public static void write (org.omg.CORBA.portable.OutputStream ostream, Address value)
 621   {
 622     ((org.omg.CORBA_2_3.portable.OutputStream) ostream).write_value (value, id ());
 623   }
 624 
 625 
 626 }
 627 </pre>
 628 
 629 <P>The Helper classes defined in the package <TT>org.omg.CORBA</TT> are:
 630 <PRE><code>
 631 &nbsp;&nbsp;&nbsp;&nbsp; <TT>AnySeqHelper
 632 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>BooleanSeqHelper
 633 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>CharSeqHelper
 634 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>CompletionStatusHelper
 635 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>CurrentHelper
 636 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>DefinitionKindHelper
 637 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>DoubleSeqHelper
 638 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>FieldNameHelper
 639 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>FloatSeqHelper
 640 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>IdentifierHelper
 641 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>IDLTypeHelper
 642 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>LongLongSeqHelper
 643 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>LongSeqHelper
 644 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>NameValuePairHelper
 645 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ObjectHelper
 646 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>OctetSeqHelper
 647 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ParameterModeHelper
 648 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>PolicyErrorCodeHelper
 649 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>PolicyErrorHelper
 650 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>PolicyHelper
 651 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>PolicyListHelper
 652 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>PolicyTypeHelper
 653 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>RepositoryIdHelper
 654 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ServiceDetailHelper
 655 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ServiceInformationHelper
 656 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>SetOverrideTypeHelper
 657 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ShortSeqHelper
 658 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>StringSeqHelper
 659 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>StringValueHelper
 660 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>StructMemberHelper
 661 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ULongLongSeqHelper
 662 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ULongSeqHelper
 663 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>UnionMemberHelper
 664 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>UnknownUserExceptionHelper
 665 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>UShortSeqHelper
 666 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ValueBaseHelper
 667 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>ValueMemberHelper
 668 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>VersionSpecHelper
 669 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>VisibilityHelper
 670 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>WCharSeqHelper
 671 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>WrongTransactionHelper
 672 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>WStringSeqHelper
 673 </TT>&nbsp;&nbsp;&nbsp;&nbsp; <TT>WStringValueHelper</TT>
 674 
 675 </code></PRE>
 676 <a name="adv"></a>
 677 <H1>
 678 Other Classes</H1>
 679 The other classes and interfaces in the <TT>CORBA</TT> package, which are
 680 used behind the scenes, can be put into four groups. Three of the groups
 681 are used with requests in some capacity, and the fourth group, concerning
 682 the Interface Repository, is a category by itself.
 683 <H2>
 684 Classes Created by an ORB</H2>
 685 The first group contains classes that are created by an ORB and contain
 686 information used in request operations. 
 687 <UL>
 688 <LI>
 689 <TT>TCKind</TT> -- indicates the kind (datatype) for a <TT>TypeCode</TT>
 690 object
 691 
 692 <LI>
 693 <TT>TypeCode</TT> -- indicates a datatype and possibly other information
 694 
 695 <LI>
 696 <TT>Any</TT> -- contains a value and its typecode
 697 
 698 <LI>
 699 <TT>NamedValue</TT> -- contains a name, an <TT>Any</TT> object, and an
 700 argument mode flag. <TT>NamedValue</TT> objects contain information about
 701 method arguments, method return values, or a context.
 702 
 703 <LI>
 704 <TT>ContextList</TT> -- a list of strings that describe the contexts that
 705 need to be resolved and sent with an invocation
 706 
 707 <LI>
 708 <TT>ExceptionList</TT> -- a list of <TT>TypeCode</TT>s for exceptions that
 709 may be thrown by a method
 710 
 711 <LI>
 712 <TT>Environment</TT> -- a container for the exception thrown during a method
 713 invocation
 714 
 715 <LI>
 716 <TT>Context</TT> -- a list of <TT>NamedValue</TT> objects used to pass
 717 auxiliary information from client to server
 718 
 719 <LI>
 720 <TT>NVList</TT> -- a list of <TT>NamedValue</TT> objects, used to pass
 721 arguments or get results
 722 </UL>
 723 
 724 <H2>
 725 Classes That Deal with Requests</H2>
 726 The second group of classes deals with requests:
 727 <UL>
 728 <LI>
 729 <TT>Object</TT> -- the base class for all CORBA object references
 730 
 731 <LI>
 732 <TT>Request</TT> -- the main class in the DII, which contains methods for
 733 adding arguments to the request, for accessing information about the method
 734 being invoked (the method name, its arguments, exceptions it throws, and
 735 so on), and for making invocations on the request
 736 
 737 <LI>
 738 <TT>DynamicImplementation</TT> -- the base class for server implementations
 739 using the DSI. It has the method <TT>invoke</TT>, which is used by an 
 740 implementation
 741 of this class to determine the state of a <TT>ServerRequest</TT> object
 742 and to set its result or exception
 743 
 744 <LI>
 745 <TT>ServerRequest</TT> -- captures the explicit state of a request for
 746 the Dynamic Skeleton Interface
 747 </UL>
 748 
 749 <H2>
 750 Interfaces That Serve as Constants</H2>
 751 The third group contains interfaces that serve as constants. The IDL-to-Java
 752 mapping mandates that IDL enums are mapped to a Java class with the enumerated
 753 values represented as public static final fields in that class (e.g. 
 754 DefinitionKind).
 755 On the other hand IDL constants defined outside of an IDL interface are
 756 mapped to a Java interface for each constant.
 757 
 758 <P>This is why several interfaces in the <TT>org.omg.CORBA</TT> package
 759 consist of a single field, <TT>value</TT>, which is a <TT>short</TT>. This
 760 field is a constant used for such things as an error code or value modifier.
 761 For example, the <TT>value</TT> field of the interface <TT>BAD_POLICY</TT>
 762 is one of the possible reasons for the exception <TT>PolicyError</TT> to
 763 be thrown. To specify this error code, you would use <TT>BAD_POLICY.value</TT>.
 764 
 765 <P>The exception <TT>PolicyError</TT> uses the <TT>value</TT> field of
 766 the following interfaces as its possible error codes.
 767 <UL>
 768 <LI>
 769 <TT>BAD_POLICY</TT>
 770 
 771 <LI>
 772 <TT>BAD_POLICY_TYPE</TT>
 773 
 774 <LI>
 775 <TT>BAD_POLICY_VALUE</TT>
 776 
 777 <LI>
 778 <TT>UNSUPPORTED_POLICY</TT>
 779 
 780 <LI>
 781 <TT>UNSUPPORTED_POLICY_VALUE</TT>
 782 </UL>
 783 The method <TT>TypeCode.type_modifier</TT> returns the <TT>value</TT> field
 784 of one of the following interfaces. The <TT>VM</TT> in the names of these
 785 interfaces stands for "value modifier."
 786 <UL>
 787 <LI>
 788 <TT>VM_NONE</TT>
 789 
 790 <LI>
 791 <TT>VM_ABSTRACT</TT>
 792 
 793 <LI>
 794 <TT>VM_CUSTOM</TT>
 795 
 796 <LI>
 797 <TT>VM_TRUNCATABLE</TT>
 798 </UL>
 799 The following constants are returned by a <code>ValueMember</code> object's
 800 access method to denote the visibility of the <code>ValueMember</code> object.
 801 <UL>
 802 <LI>
 803 <TT>PRIVATE_MEMBER</TT>
 804 
 805 <LI>
 806 <TT>PUBLIC_MEMBER</TT>
 807 </UL>
 808 These flags, used in <TT>NamedValue</TT> objects or as parameters to methods,
 809 are defined in the following interfaces:
 810 <UL>
 811 <LI>
 812 <TT>ARG_IN</TT>
 813 
 814 <LI>
 815 <TT>ARG_INOUT</TT>
 816 
 817 <LI>
 818 <TT>ARG_OUT</TT>
 819 
 820 <LI>
 821 <TT>CTX_RESTRICT_SCOPE</TT>
 822 </UL>
 823 
 824 <H2>
 825 Interface Repository Interfaces and Classes</H2>
 826 A fourth group contains the Interface Repository interfaces and classes,
 827 which are generated by the <TT>idlj</TT> compiler from the OMG IDL
 828 interface <TT>ir.idl</TT>. The purpose of the Interface Repository is to
 829 identify the interfaces stored in it so that they can be accessed by an
 830 ORB. Each module, type, interface, attribute, operation, parameter, exception,
 831 constant, and so on is described completely by the Interface Repository
 832 API.
 833 
 834 <P>An ORB does not require that there be an interface repository, and Java
 835 IDL does not include one. Even though this release does not include an
 836 implementation of an interface repository, the following IR classes and
 837 interfaces have been included for the purpose of creating typecodes (see
 838 create_value_tc, create_struct_tc, create_union_tc and create_exception_tc
 839 methods in interface org.omg.CORBA.ORB):
 840 <BR>&nbsp;
 841 <UL>
 842 <LI>
 843 IRObject
 844 
 845 <LI>
 846 IDLType
 847 
 848 <LI>


 857 <LI>
 858 ValueMember
 859 </UL>
 860 <!-- End Page Data -->
 861 <HR>
 862 <H1>
 863 Related Documentation</H1>
 864 For overviews, guides, and a tutorial, please see:
 865 <UL>
 866 <LI>
 867 <A HREF="{@docRoot}/../technotes/guides/idl/index.html">Java IDL home page</A>
 868 </UL>
 869 
 870 
 871 
 872 
 873 <P><A NAME="unimpl"></A>
 874 <H1>
 875 CORBA Features Not Implemented in Java IDL</H1>
 876 
 877 <P>Some of the API included in <TT>org.omg</TT> subpackages is provided for
 878 conformance with the current OMG CORBA specification but is not implemented
 879 in Sun's release of the JDK<SUP><FONT SIZE=-2>TM</FONT></SUP>. This enables
 880 other JDK licensees to provide implementations of this API in standard
 881 extensions and products.
 882 
 883 <P><A NAME="NO_IMPLEMENT"></A>
 884 <h2>Features That Throw NO_IMPLEMENT</h2>
 885 
 886 <P>Some of the API included in <TT>org.omg</TT> subpackages throw 
 887 <tt>NO_IMPLEMENT</tt> exceptions for various reasons.  Among these reasons
 888 are:
 889     <UL>
 890     <LI>In some cases, for example <tt>LocalObject</tt>, the complete
 891     implementation according to the specification indicates that 
 892     these API should throw <tt>NO_IMPLEMENT</tt>.
 893 
 894     <LI>In most cases, for example methods in <tt>ORB.java</tt>, 
 895     methods that throw  
 896     <tt>NO_IMPLEMENT</tt> are actually implemented in subclasses
 897     elsewhere in the ORB code.
 898 
 899     <LI>In some cases, for example <tt>_get_interface_def()</tt> 
 900     and <tt>_get_interface</tt>, API are really not yet implemented.
 901     </UL>
 902 
 903 
 904 
 905 
 906 <H2>
 907 General Summary of Features or API Not Implemented in This Release:</H2>
 908 
 909 <UL>
 910 <LI>
 911 Interface Repository. An Interface Repository is not required for normal
 912 operation of Java IDL.
 913 
 914 <LI>
 915 Java IDL does not support <TT>long double</TT>.  
 916 
 917 
 918 <LI>
 919 Policies (<TT><a href="Policy.html">org.omg.CORBA.Policy</a></TT>) and methods for getting them are not implemented.

 920 
 921 <LI>
 922 Domain managers (<TT><a href="DomainManager.html">org.omg.CORBA.DomainManager</a></TT>) and methods for
 923 getting them are not implemented.
 924 
 925 <LI>
 926 Service Information <TT><a href="ServiceInformation.html">org.omg.CORBA.ServiceInformation</a></TT> and ORB method <TT>public boolean get_service_information(short service_type, 
 927 ServiceInformationHolder
 928 service_info)</TT>  are not implemented.

 929 
 930 <LI>ORB methods for supporting single-threading (<tt>perform_work</tt>, <tt>work_pending</tt>) are not implemented.

 931 
 932 <LI>IDL contexts.
 933 </UL>
 934 
 935 <HR>
 936 <H2>
 937 Specific List of Unimplemented Features in Package <TT>org.omg.CORBA</TT></H2>
 938 
 939 
 940 <H3>
 941 Unimplemented Methods in package <TT>org.omg.CORBA</TT>:</H3>
 942 
 943 <UL>
 944 <LI>
 945 <TT>ORB</TT>
 946 
 947 <UL>
 948 <LI>
 949 <TT>public org.omg.CORBA.Policy create_policy(int type, org.omg.CORBA.Any
 950 val)</TT>
 951 
 952 
 953 
 954 <LI>
 955 <TT>public void perform_work()</TT>
 956 
 957 <LI>
 958 <TT>public boolean work_pending()</TT>
 959 
 960 <LI>
 961 <TT>public org.omg.CORBA.Current get_current()</TT>
 962 
 963 <LI>
 964 <TT>create_operation_list</TT>
 965 
 966 <LI>
 967 <TT>get_default_context</TT>
 968 
 969 <LI>
 970 <TT>get_service_information</TT>
 971 
 972 <LI>
 973 obsolete <TT>DynAnys</TT> (deprecated in favor of <tt>DynamicAny</tt> package)
 974 
 975 
 976 </UL>
 977 
 978 
 979 
 980 </UL>
 981 @since JDK1.2
 982 @serial exclude
 983 </BODY>
 984 </HTML>


  17 *
  18 * This code is distributed in the hope that it will be useful, but WITHOUT
  19 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  20 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  21 * version 2 for more details (a copy is included in the LICENSE file that
  22 * accompanied this code).
  23 *
  24 * You should have received a copy of the GNU General Public License version
  25 * 2 along with this work; if not, write to the Free Software Foundation,
  26 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  27 *
  28 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  29 * or visit www.oracle.com if you need additional information or have any
  30 * questions.
  31 */  
  32 -->
  33 </HEAD>
  34 <BODY BGCOLOR="#FFFFFF">
  35 Provides the mapping of the OMG CORBA APIs to the Java<SUP><FONT 
  36 SIZE=-2>TM</FONT></SUP>
  37 programming language, including the class <code>ORB</code>, which is implemented
  38 so that a programmer can use it as a fully-functional Object Request Broker
  39 (ORB).
  40 
  41 <P>For a precise list of supported sections of official CORBA specifications with which
  42 the Java[TM] Platform, Standard Edition 6 complies, see <A
  43 HREF="doc-files/compliance.html"><em>Official Specifications for CORBA support in
  44 Java[TM] SE 6</em></A>.
  45 
  46 
  47 <H1>General Information</H1>
  48 The information in this section is information relevant to someone who
  49 compiles Interface Definition Language (IDL) files and uses the
  50 ORB to write clients and servers.
  51 
  52 <P>The classes and interfaces described in this section can be put into
  53 four groups: <code>ORB classes</code>, Exceptions, <code>Helper</code> classes,
  54 and <code>Holder</code> classes.
  55 
  56 <H2>
  57 The <code>ORB</code> Class</H2>
  58 
  59 <P>An ORB handles (or brokers) method invocations between a client and
  60 the method's implementation on a server. Because the client and server
  61 may be anywhere on a network, and because the invocation and implementation
  62 may be written in different programming languages, an ORB does a great
  63 deal of work behind the scenes to accomplish this communication.
  64 
  65 <P>Most of what an ORB does is completely transparent to the user, and a major
  66 portion of the <code>CORBA</code> package consists of classes used by the ORB
  67 behind the scenes. The result is that most programmers will use only a
  68 small part of this package directly. In fact, most programmers will use
  69 only a few methods from the <code>ORB</code> class, some exceptions, and
  70 occasionally,
  71 a holder class.
  72 <H3>
  73 <code>ORB</code> Methods</H3>
  74 
  75 <P>Before an application can enter the CORBA environment, it must first:
  76 <UL>
  77 <LI>Be initialized into the ORB and possibly the object adapter (POA) environments.
  78 <LI>Get references to ORB object (for use in future ORB operations)
  79 and perhaps other objects (including the root POA or some Object Adapter objects).
  80 </UL>
  81 <P>The following operations are provided to initialize applications and obtain
  82  the appropriate object references:
  83  <UL>
  84  <LI>Operations providing access to the ORB, which are discussed in this
  85  section.
  86  <LI>Operations providing access to Object Adapters, Interface Repository,
  87  Naming Service, and other Object Services. These operations are described
  88  in <a href="#adv"><em>Other Classes</em></a>.
  89  </UL>
  90  <P>
  91 When an application requires a CORBA environment it needs a mechanism to
  92 get an ORB object reference and possibly an OA object reference
  93 (such as the root POA). This serves two purposes. First, it initializes
  94 an application into the ORB and OA environments. Second, it returns the
  95 ORB object reference and the OA object reference to the application
  96 for use in future ORB and OA operations.
  97 
  98 <P>In order to obtain an ORB object reference, applications call
  99 the <code>ORB.init</code> operation. The parameters to the call can comprise an
 100 identifier for the ORB for which the object reference is required,
 101  and an arg_list, which is used to allow environment-specific data to be
 102  passed into the call.
 103 
 104 <P>These are the <code>ORB</code> methods
 105  that provide access to the ORB:
 106 <UL>
 107 <LI>
 108 <code><b>init</b>()</code>
 109 
 110 <LI>
 111 <code><b>init</b>(String [] args, Properties props)</code>
 112 
 113 <LI>
 114 <code><b>init</b>(Applet app, Properties props)</code>
 115 </UL>
 116 
 117 <P>Using the <code>init()</code> method without parameters initiates
 118 a singleton ORB,  which can only
 119 give typecode creation <code>any</code>s needed in code generated
 120 in Helper classes by <code>idlj</code>.
 121 
 122 <P>Applications require a portable means by which to obtain their
 123 initial object references. References are required for the root
 124 POA, POA Current, Interface Repository, and various Object Services
 125 instances.  The functionality required by the application is similar
 126  to that provided by the Naming Service. However, the OMG does not
 127  want to mandate that the Naming Service be made available to all
 128  applications in order that they may be portably initialized.
 129  Consequently, the operations shown in this section provide a
 130  simplified, local version of the Naming Service that applications
 131  can use to obtain a small, defined set of object references which
 132  are essential to its operation. Because only a small well-defined
 133  set of objects are expected with this mechanism, the naming context
 134  can be flattened to be a single-level name space. This simplification
 135  results in only two operations being defined to achieve the functionality
 136   required.
 137   
 138 <P>Initial references are obtained via two operations provided in
 139 the ORB object interface, providing facilities to list and
 140 resolve initial object references.  These are:
 141 <UL>
 142 <LI>
 143 <code><b>resolve_initial_references</b>(String name)</code>
 144 <LI>
 145 <code><b>list_initial_services</b>()</code>
 146 <LI>
 147 <code><b>register_initial_reference</b>(String id, org.omg.CORBA.Object obj)</code>

 148 </UL>
 149 
 150 <P>An example that uses some of these methods is <A
 151 HREF="{@docRoot}/../technotes/guides/idl/GShome.html">
 152 <em>Getting Started with Java IDL</em></A>.
 153 
 154 <H2>
 155 Exceptions</H2>
 156 Exceptions in Java IDL are similar to those in any code written in the
 157 Java programming language. If a method is defined to throw an exception,
 158 then any code using that method must have a <code>try</code>/<code>catch</code>
 159 block and handle that exception when it is thrown.
 160 
 161 <P>The documentation on <A 
 162 HREF="{@docRoot}/../technotes/guides/idl/jidlExceptions.html"><em>Java
 163 IDL exceptions</em></A> has more information and explains the difference between
 164 system exceptions and user-defined exceptions.
 165 
 166 <P>The following is a list of the system exceptions (which are unchecked
 167 exceptions inheriting through <code><a href="SystemException.html">
 168 org.omg.CORBA.SystemException</a></code> from
 169 <code>java.lang.RuntimeException</code>) that are defined in the package
 170 <code>org.omg.CORBA</code>:
 171 <PRE><code>
 172 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BAD_CONTEXT
 173 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BAD_INV_ORDER
 174 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BAD_OPERATION
 175 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BAD_PARAM
 176 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BAD_TYPECODE
 177 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; COMM_FAILURE
 178 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DATA_CONVERSION
 179 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FREE_MEM
 180 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMP_LIMIT
 181 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INITIALIZE
 182 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTERNAL
 183 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTF_REPOS
 184 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INVALID_TRANSACTION
 185 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INV_FLAG
 186 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INV_IDENT
 187 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INV_OBJREF
 188 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INV_POLICY
 189 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MARSHAL
 190 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="#NO_IMPLEMENT">NO_IMPLEMENT</a>
 191 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO_MEMORY
 192 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO_PERMISSION
 193 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO_RESOURCES
 194 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO_RESPONSE
 195 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT_NOT_EXIST
 196 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJ_ADAPTER
 197 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PERSIST_STORE
 198 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TRANSACTION_REQUIRED
 199 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TRANSACTION_ROLLEDBACK
 200 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TRANSIENT
 201 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UNKNOWN
 202 </code></PRE>
 203 <P>
 204 The following is a list of user-defined exceptions defined in the package
 205 <code>org.omg.CORBA</code>.
 206 <PRE><code>
 207 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bounds
 208 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UnknownUserException
 209 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WrongTransaction&nbsp;
 210 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PolicyError
 211 </code></PRE>
 212 
 213  <H2>Subpackages</H2>
 214 There are some packages inside the <code>CORBA</code> package with
 215 "Package" as part of their names. These packages are generally quite small
 216 because all they do is provide exceptions or classes for use by interfaces
 217 and classes in the <code>CORBA</code> package.
 218 
 219 <P>For example, the package <code><a href="TypeCodePackage/package-summary.html">
 220 org.omg.CORBA.TypeCodePackage</a></code> contains
 221 two exceptions thrown by methods in the class <code>TypeCode</code>. These
 222 exceptions are:
 223 <UL>
 224 <LI>
 225 <code>BadKind</code>
 226 
 227 <LI>
 228 <code>Bounds</code>
 229 </UL>
 230 The package <code><a href="ORBPackage/package-summary.html">
 231 org.omg.CORBA.ORBPackage</a></code> contains two exceptions:
 232 <UL>
 233 <LI>
 234 <code>InvalidName</code>
 235 
 236 <LI>
 237 <code>InconsistentTypeCode</code>
 238 </UL>
 239 
 240 <P>Another package that is a subpackage of <code>CORBA</code> is the
 241 <code><a href="portable/package-summary.html">portable</a></code>
 242 package. It provides a set of ORB APIs that makes it
 243 possible for code generated by one vendor's IDL compiler to run
 244 on another vendor's ORB.
 245 
 246 
 247 
 248 
 249 <H2>
 250 Holder classes</H2>
 251  
 252 
 253 <P>Support for out and inout parameter passing modes requires the use of
 254 additional  <em><a href="doc-files/generatedfiles.html#holder">holder
 255 classes</a></em>. Because the Java programming language does not support out or
 256 inout parameters, holder classes are needed as a means of passing a parameter
 257 that can be modified. To support portable stubs and skeletons,
 258 holder classes also implement the
 259 <code><a href="portable/Streamable.html">org.omg.CORBA.portable.Streamable</a></code>
 260 interface.
 261  
 262  <P>Holder classes are named by appending "Holder" to the name of the type.
 263  The name of the type refers to its name in the Java programming language.  For
 264  example, a holder class for the interface named <code>Account</code>
 265  in the Java programming
 266  language would be named <code>AccountHolder</code>.
 267 
 268 
 269 <P>Holder classes are available for all of the basic IDL
 270  datatypes in the <code>org.omg.CORBA</code> package.  So, for example,
 271  there are already-defined classes for <code>LongHolder</code>, <code>ShortHolder</code>,
 272  <code>FloatHolder</code>, and so on.  Classes are also generated for
 273  all named user-defined IDL types except those defined by <code>typedefs</code>.
 274  (Note that in this context user defined includes types that are
 275  defined in OMG specifications such as those for the Interface
 276   Repository, and other OMG services.)
 277 
 278 
 279 <P>Each holder class has:
 280 <UL>
 281 <LI>a constructor from an instance
 282 <LI>a default constructor
 283 <LI>a public instance member, <code>value</code> which is the typed value.
 284 <LI>a method for reading an input stream and assigning the contents to the
 285 type's <code>value</code> field
 286 <LI>a method for writing the value of the <code>value</code> field to an output stream
 287 <LI>a method for getting the typecode of the type
 288 </UL>
 289 
 290 <P>The default constructor sets the value field to the default value for the
 291 type as defined by the Java language:
 292 <UL>
 293 <LI><code>false</code> for boolean
 294 <LI><code>0</code> for numeric and char types
 295 <LI><code>null</code> for strings and object references
 296 </UL>
 297 
 298 
 299 
 300 <P>
 301 As an example, if the interface <code>Account</code>, defined in OMG IDL,
 302 were mapped to the Java programming language, the following holder class
 303 would be generated:
 304 <PRE>
 305 public final class AccountHolder implements
 306     org.omg.CORBA.portable.Streamable
 307 {
 308   // field that holds an Account object
 309   public Account value = null;
 310 
 311   // default constructor
 312   public AccountHolder ()
 313   {
 314   }
 315   


 326   }
 327 
 328   // writes value to o
 329   public void _write (org.omg.CORBA.portable.OutputStream o)
 330   {
 331     AccountHelper.write (o, value);
 332   }
 333  
 334   // returns the typecode for Account
 335   public org.omg.CORBA.TypeCode _type ()
 336   {
 337     return AccountHelper.type ();
 338   }
 339 
 340 }
 341 </PRE>
 342 
 343 <P>For more information on Holder classes, see Chapter 1.4, <em>Mapping for
 344 Basic Types</em> in the <a href="http://www.omg.org/cgi-bin/doc?ptc/00-01-08">
 345 <em>OMG IDL to Java Language Mapping</em></a>. The Holder classes defined 
 346 in the package <code>org.omg.CORBA</code> are:
 347 <PRE><code>
 348 &nbsp;&nbsp;&nbsp;&nbsp; AnyHolder
 349 &nbsp;&nbsp;&nbsp;&nbsp; AnySeqHolder
 350 &nbsp;&nbsp;&nbsp;&nbsp; BooleanHolder
 351 &nbsp;&nbsp;&nbsp;&nbsp; BooleanSeqHolder
 352 &nbsp;&nbsp;&nbsp;&nbsp; ByteHolder
 353 &nbsp;&nbsp;&nbsp;&nbsp; CharHolder
 354 &nbsp;&nbsp;&nbsp;&nbsp; CharSeqHolder
 355 &nbsp;&nbsp;&nbsp;&nbsp; CurrentHolder
 356 &nbsp;&nbsp;&nbsp;&nbsp; DoubleHolder
 357 &nbsp;&nbsp;&nbsp;&nbsp; DoubleSeqHolder
 358 &nbsp;&nbsp;&nbsp;&nbsp; FixedHolder
 359 &nbsp;&nbsp;&nbsp;&nbsp; FloatHolder
 360 &nbsp;&nbsp;&nbsp;&nbsp; FloatSeqHolder
 361 &nbsp;&nbsp;&nbsp;&nbsp; IntHolder
 362 &nbsp;&nbsp;&nbsp;&nbsp; LongHolder
 363 &nbsp;&nbsp;&nbsp;&nbsp; LongLongSeqHolder
 364 &nbsp;&nbsp;&nbsp;&nbsp; LongSeqHolder
 365 &nbsp;&nbsp;&nbsp;&nbsp; ObjectHolder
 366 &nbsp;&nbsp;&nbsp;&nbsp; OctetSeqHolder
 367 &nbsp;&nbsp;&nbsp;&nbsp; ParameterModeHolder
 368 &nbsp;&nbsp;&nbsp;&nbsp; PolicyErrorHolder
 369 &nbsp;&nbsp;&nbsp;&nbsp; PolicyListHolder
 370 &nbsp;&nbsp;&nbsp;&nbsp; PrincipalHolder
 371 &nbsp;&nbsp;&nbsp;&nbsp; ServiceInformationHolder
 372 &nbsp;&nbsp;&nbsp;&nbsp; ShortHolder
 373 &nbsp;&nbsp;&nbsp;&nbsp; ShortSeqHolder
 374 &nbsp;&nbsp;&nbsp;&nbsp; StringHolder
 375 &nbsp;&nbsp;&nbsp;&nbsp; StringSeqHolder
 376 &nbsp;&nbsp;&nbsp;&nbsp; TypeCodeHolder
 377 &nbsp;&nbsp;&nbsp;&nbsp; ULongLongSeqHolder
 378 &nbsp;&nbsp;&nbsp;&nbsp; ULongSeqHolder
 379 &nbsp;&nbsp;&nbsp;&nbsp; UnknownUserExceptionHolder
 380 &nbsp;&nbsp;&nbsp;&nbsp; UShortSeqHolder
 381 &nbsp;&nbsp;&nbsp;&nbsp; ValueBaseHolder
 382 &nbsp;&nbsp;&nbsp;&nbsp; WCharSeqHolder
 383 &nbsp;&nbsp;&nbsp;&nbsp; WrongTransactionHolder
 384 &nbsp;&nbsp;&nbsp;&nbsp; WStringSeqHolder
 385 </code></PRE>

 386 
 387 <h2>Helper Classes </h2>
 388 <P>Helper files supply several static methods needed to manipulate the type.
 389  These include:
 390  <UL>
 391  <LI><code>Any</code> insert and extract operations for the type
 392  <LI>getting the repository id
 393  <LI>getting the typecode
 394  <LI>reading and writing the type from and to a stream
 395  <LI>implement the <code>ValueHelper</code> interface (if it is  a user-defined
 396    value type)
 397  </UL> 
 398 
 399 <P>The helper class for a mapped IDL interface or abstract interface
 400 also include narrow operation(s). The static narrow method allows
 401 an <code>org.omg.CORBA.Object</code> to be narrowed to the object reference
 402 of a more specific type. The IDL exception <code>CORBA.BAD_PARAM</code>
 403 is thrown if the narrow fails because the object reference does not
 404 support the requested type. A different system exception is raised
 405 to indicate other kinds of errors. Trying to narrow a <code>null</code> will always
 406 succeed with a return value of <code>null</code>.
 407 Generally, the only helper method an application programmer uses is
 408 the <code>narrow</code> method.  The other methods are normally used behind
 409 the scenes and are transparent to the programmer.
 410 
 411 <P>Helper classes
 412 fall into two broad categories, <a href="#value">helpers for value types</a> and
 413 <a href="#basic">helpers for non value types</a>. Because all of the helper
 414 classes in one category
 415 provide the same methods, one generic explanation of each
 416 category of helper classes is presented here.
 417 
 418 <P>
 419 When OMG IDL is mapped to the Java programming language,
 420 a "helper" class is generated for each user-defined type.
 421 This generated class will have the name of the user-defined type with
 422 the suffix <code>Helper</code> appended.  For example, if the
 423 interface <code>Account</code> is defined in OMG IDL, the
 424 <code>idlj</code> compiler will automatically generate a class named
 425 <code>AccountHelper</code>.  The <code>AccountHelper</code> class
 426 will contain the static methods needed for manipulating instances of the type,
 427 in this case, <code>Account</code> objects.
 428 
 429 
 430 <a name="narrow"></a>
 431 <h3>The <code>narrow</code> Method</h3>
 432 When an object is the return value for a method, it is returned in the
 433 form of a generic object, either an <code>org.omg.CORBA.Object</code> object
 434 or a <code>java.lang.Object</code> object. This object must be cast to its
 435 more specific type before it can be operated on.  For example, an
 436 <code>Account</code> object will be returned as a generic object and must
 437 be narrowed to an <code>Account</code> object so that <code>Account</code>
 438 methods may be called on it.
 439 <P>
 440 The <code>narrow</code> method has two forms, one that takes an
 441 <code>org.omg.CORBA.Object</code> object and one that takes a
 442 <code>java.lang.Object</code> object. Whether the interface is abstract or
 443 not determines which <code>narrow</code> method its helper class will provide.
 444 The helper class for an interface
 445 that is not abstract will have a <code>narrow</code> method that takes a CORBA
 446 object, whereas the <code>narrow</code> method for an interface that is abstract
 447 will take an object in the Java programming language.  The helper class for a

 448 non-abstract interface that has at least one abstract base interface will provide
 449 both versions of the <code>narrow</code> method.
 450 <P>The <A HREF="{@docRoot}/../technotes/guides/idl/jidlExample.html"><em>Hello World</em></A>
 451 tutorial uses a <code>narrow</code> method that looks like this:

 452 <PRE>
 453         // create and initialize the ORB
 454         ORB orb = ORB.init(args, null);
 455 
 456         // get the root naming context
 457         org.omg.CORBA.Object objRef = 
 458             orb.resolve_initial_references("NameService");
 459         // Use NamingContextExt instead of NamingContext. This is 
 460         // part of latest Inter-Operable naming Service.  
 461         NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
 462  
 463         // resolve the Object Reference in Naming
 464         String name = "Hello";
 465         helloImpl = HelloHelper.narrow(ncRef.resolve_str(name));
 466 </PRE>
 467 
 468 <a name="basic"></a>
 469 <h3>Example of a Basic Helper Class</h3>
 470 A basic helper class, for purposes of this explanation, is one with
 471 the methods that are provided by every helper class, plus a <code>narrow</code>


 608   {
 609     return _id;
 610   }
 611 
 612   // reads a serializable instance of Address from the given input stream
 613   public static Address read (org.omg.CORBA.portable.InputStream istream)
 614   {
 615     return (Address)((org.omg.CORBA_2_3.portable.InputStream) istream).read_value (id ());
 616   }
 617 
 618   // writes a serializable instance of Address to the given output stream
 619   public static void write (org.omg.CORBA.portable.OutputStream ostream, Address value)
 620   {
 621     ((org.omg.CORBA_2_3.portable.OutputStream) ostream).write_value (value, id ());
 622   }
 623 
 624 
 625 }
 626 </pre>
 627 
 628 <P>The Helper classes defined in the package <code>org.omg.CORBA</code> are:
 629 <PRE><code>
 630 &nbsp;&nbsp;&nbsp;&nbsp; AnySeqHelper
 631 &nbsp;&nbsp;&nbsp;&nbsp; BooleanSeqHelper
 632 &nbsp;&nbsp;&nbsp;&nbsp; CharSeqHelper
 633 &nbsp;&nbsp;&nbsp;&nbsp; CompletionStatusHelper
 634 &nbsp;&nbsp;&nbsp;&nbsp; CurrentHelper
 635 &nbsp;&nbsp;&nbsp;&nbsp; DefinitionKindHelper
 636 &nbsp;&nbsp;&nbsp;&nbsp; DoubleSeqHelper
 637 &nbsp;&nbsp;&nbsp;&nbsp; FieldNameHelper
 638 &nbsp;&nbsp;&nbsp;&nbsp; FloatSeqHelper
 639 &nbsp;&nbsp;&nbsp;&nbsp; IdentifierHelper
 640 &nbsp;&nbsp;&nbsp;&nbsp; IDLTypeHelper
 641 &nbsp;&nbsp;&nbsp;&nbsp; LongLongSeqHelper
 642 &nbsp;&nbsp;&nbsp;&nbsp; LongSeqHelper
 643 &nbsp;&nbsp;&nbsp;&nbsp; NameValuePairHelper
 644 &nbsp;&nbsp;&nbsp;&nbsp; ObjectHelper
 645 &nbsp;&nbsp;&nbsp;&nbsp; OctetSeqHelper
 646 &nbsp;&nbsp;&nbsp;&nbsp; ParameterModeHelper
 647 &nbsp;&nbsp;&nbsp;&nbsp; PolicyErrorCodeHelper
 648 &nbsp;&nbsp;&nbsp;&nbsp; PolicyErrorHelper
 649 &nbsp;&nbsp;&nbsp;&nbsp; PolicyHelper
 650 &nbsp;&nbsp;&nbsp;&nbsp; PolicyListHelper
 651 &nbsp;&nbsp;&nbsp;&nbsp; PolicyTypeHelper
 652 &nbsp;&nbsp;&nbsp;&nbsp; RepositoryIdHelper
 653 &nbsp;&nbsp;&nbsp;&nbsp; ServiceDetailHelper
 654 &nbsp;&nbsp;&nbsp;&nbsp; ServiceInformationHelper
 655 &nbsp;&nbsp;&nbsp;&nbsp; SetOverrideTypeHelper
 656 &nbsp;&nbsp;&nbsp;&nbsp; ShortSeqHelper
 657 &nbsp;&nbsp;&nbsp;&nbsp; StringSeqHelper
 658 &nbsp;&nbsp;&nbsp;&nbsp; StringValueHelper
 659 &nbsp;&nbsp;&nbsp;&nbsp; StructMemberHelper
 660 &nbsp;&nbsp;&nbsp;&nbsp; ULongLongSeqHelper
 661 &nbsp;&nbsp;&nbsp;&nbsp; ULongSeqHelper
 662 &nbsp;&nbsp;&nbsp;&nbsp; UnionMemberHelper
 663 &nbsp;&nbsp;&nbsp;&nbsp; UnknownUserExceptionHelper
 664 &nbsp;&nbsp;&nbsp;&nbsp; UShortSeqHelper
 665 &nbsp;&nbsp;&nbsp;&nbsp; ValueBaseHelper
 666 &nbsp;&nbsp;&nbsp;&nbsp; ValueMemberHelper
 667 &nbsp;&nbsp;&nbsp;&nbsp; VersionSpecHelper
 668 &nbsp;&nbsp;&nbsp;&nbsp; VisibilityHelper
 669 &nbsp;&nbsp;&nbsp;&nbsp; WCharSeqHelper
 670 &nbsp;&nbsp;&nbsp;&nbsp; WrongTransactionHelper
 671 &nbsp;&nbsp;&nbsp;&nbsp; WStringSeqHelper
 672 &nbsp;&nbsp;&nbsp;&nbsp; WStringValueHelper

 673 </code></PRE>
 674 <a name="adv"></a>
 675 <H1>
 676 Other Classes</H1>
 677 The other classes and interfaces in the <code>CORBA</code> package, which are
 678 used behind the scenes, can be put into four groups. Three of the groups
 679 are used with requests in some capacity, and the fourth group, concerning
 680 the Interface Repository, is a category by itself.
 681 <H2>
 682 Classes Created by an ORB</H2>
 683 The first group contains classes that are created by an ORB and contain
 684 information used in request operations. 
 685 <UL>
 686 <LI>
 687 <code>TCKind</code> -- indicates the kind (datatype) for a <code>TypeCode</code>
 688 object
 689 
 690 <LI>
 691 <code>TypeCode</code> -- indicates a datatype and possibly other information
 692 
 693 <LI>
 694 <code>Any</code> -- contains a value and its typecode
 695 
 696 <LI>
 697 <code>NamedValue</code> -- contains a name, an <code>Any</code> object, and an
 698 argument mode flag. <code>NamedValue</code> objects contain information about
 699 method arguments, method return values, or a context.
 700 
 701 <LI>
 702 <code>ContextList</code> -- a list of strings that describe the contexts that
 703 need to be resolved and sent with an invocation
 704 
 705 <LI>
 706 <code>ExceptionList</code> -- a list of <code>TypeCode</code>s for exceptions that
 707 may be thrown by a method
 708 
 709 <LI>
 710 <code>Environment</code> -- a container for the exception thrown during a method
 711 invocation
 712 
 713 <LI>
 714 <code>Context</code> -- a list of <code>NamedValue</code> objects used to pass
 715 auxiliary information from client to server
 716 
 717 <LI>
 718 <code>NVList</code> -- a list of <code>NamedValue</code> objects, used to pass
 719 arguments or get results
 720 </UL>
 721 
 722 <H2>
 723 Classes That Deal with Requests</H2>
 724 The second group of classes deals with requests:
 725 <UL>
 726 <LI>
 727 <code>Object</code> -- the base class for all CORBA object references
 728 
 729 <LI>
 730 <code>Request</code> -- the main class in the DII, which contains methods for
 731 adding arguments to the request, for accessing information about the method
 732 being invoked (the method name, its arguments, exceptions it throws, and
 733 so on), and for making invocations on the request
 734 
 735 <LI>
 736 <code>DynamicImplementation</code> -- the base class for server implementations
 737 using the DSI. It has the method <code>invoke</code>, which is used by an 
 738 implementation
 739 of this class to determine the state of a <code>ServerRequest</code> object
 740 and to set its result or exception
 741 
 742 <LI>
 743 <code>ServerRequest</code> -- captures the explicit state of a request for
 744 the Dynamic Skeleton Interface
 745 </UL>
 746 
 747 <H2>
 748 Interfaces That Serve as Constants</H2>
 749 The third group contains interfaces that serve as constants. The IDL-to-Java
 750 mapping mandates that IDL enums are mapped to a Java class with the enumerated
 751 values represented as public static final fields in that class (e.g.
 752 DefinitionKind).
 753 On the other hand IDL constants defined outside of an IDL interface are
 754 mapped to a Java interface for each constant.
 755 
 756 <P>This is why several interfaces in the <code>org.omg.CORBA</code> package
 757 consist of a single field, <code>value</code>, which is a <code>short</code>. This
 758 field is a constant used for such things as an error code or value modifier.
 759 For example, the <code>value</code> field of the interface <code>BAD_POLICY</code>
 760 is one of the possible reasons for the exception <code>PolicyError</code> to
 761 be thrown. To specify this error code, you would use <code>BAD_POLICY.value</code>.
 762 
 763 <P>The exception <code>PolicyError</code> uses the <code>value</code> field of
 764 the following interfaces as its possible error codes.
 765 <UL>
 766 <LI>
 767 <code>BAD_POLICY</code>
 768 
 769 <LI>
 770 <code>BAD_POLICY_TYPE</code>
 771 
 772 <LI>
 773 <code>BAD_POLICY_VALUE</code>
 774 
 775 <LI>
 776 <code>UNSUPPORTED_POLICY</code>
 777 
 778 <LI>
 779 <code>UNSUPPORTED_POLICY_VALUE</code>
 780 </UL>
 781 The method <code>TypeCode.type_modifier</code> returns the <code>value</code> field
 782 of one of the following interfaces. The <code>VM</code> in the names of these
 783 interfaces stands for "value modifier."
 784 <UL>
 785 <LI>
 786 <code>VM_NONE</code>
 787 
 788 <LI>
 789 <code>VM_ABSTRACT</code>
 790 
 791 <LI>
 792 <code>VM_CUSTOM</code>
 793 
 794 <LI>
 795 <code>VM_TRUNCATABLE</code>
 796 </UL>
 797 The following constants are returned by a <code>ValueMember</code> object's
 798 access method to denote the visibility of the <code>ValueMember</code> object.
 799 <UL>
 800 <LI>
 801 <code>PRIVATE_MEMBER</code>
 802 
 803 <LI>
 804 <code>PUBLIC_MEMBER</code>
 805 </UL>
 806 These flags, used in <code>NamedValue</code> objects or as parameters to methods,
 807 are defined in the following interfaces:
 808 <UL>
 809 <LI>
 810 <code>ARG_IN</code>
 811 
 812 <LI>
 813 <code>ARG_INOUT</code>
 814 
 815 <LI>
 816 <code>ARG_OUT</code>
 817 
 818 <LI>
 819 <code>CTX_RESTRICT_SCOPE</code>
 820 </UL>
 821 
 822 <H2>
 823 Interface Repository Interfaces and Classes</H2>
 824 A fourth group contains the Interface Repository interfaces and classes,
 825 which are generated by the <code>idlj</code> compiler from the OMG IDL
 826 interface <code>ir.idl</code>. The purpose of the Interface Repository is to
 827 identify the interfaces stored in it so that they can be accessed by an
 828 ORB. Each module, type, interface, attribute, operation, parameter, exception,
 829 constant, and so on is described completely by the Interface Repository
 830 API.
 831 
 832 <P>An ORB does not require that there be an interface repository, and Java
 833 IDL does not include one. Even though this release does not include an
 834 implementation of an interface repository, the following IR classes and
 835 interfaces have been included for the purpose of creating typecodes (see
 836 create_value_tc, create_struct_tc, create_union_tc and create_exception_tc
 837 methods in interface org.omg.CORBA.ORB):
 838 <BR>&nbsp;
 839 <UL>
 840 <LI>
 841 IRObject
 842 
 843 <LI>
 844 IDLType
 845 
 846 <LI>


 855 <LI>
 856 ValueMember
 857 </UL>
 858 <!-- End Page Data -->
 859 <HR>
 860 <H1>
 861 Related Documentation</H1>
 862 For overviews, guides, and a tutorial, please see:
 863 <UL>
 864 <LI>
 865 <A HREF="{@docRoot}/../technotes/guides/idl/index.html">Java IDL home page</A>
 866 </UL>
 867 
 868 
 869 
 870 
 871 <P><A NAME="unimpl"></A>
 872 <H1>
 873 CORBA Features Not Implemented in Java IDL</H1>
 874 
 875 <P>Some of the API included in <code>org.omg</code> subpackages is provided for
 876 conformance with the current OMG CORBA specification but is not implemented
 877 in Sun's release of the JDK<SUP><FONT SIZE=-2>TM</FONT></SUP>. This enables
 878 other JDK licensees to provide implementations of this API in standard
 879 extensions and products.
 880 
 881 <P><A NAME="NO_IMPLEMENT"></A>
 882 <h2>Features That Throw NO_IMPLEMENT</h2>
 883 
 884 <P>Some of the API included in <code>org.omg</code> subpackages throw
 885 <code>NO_IMPLEMENT</code> exceptions for various reasons.  Among these reasons
 886 are:
 887     <UL>
 888     <LI>In some cases, for example <code>LocalObject</code>, the complete
 889     implementation according to the specification indicates that
 890     these API should throw <code>NO_IMPLEMENT</code>.
 891 
 892     <LI>In most cases, for example methods in <code>ORB.java</code>,
 893     methods that throw
 894     <code>NO_IMPLEMENT</code> are actually implemented in subclasses
 895     elsewhere in the ORB code.
 896 
 897     <LI>In some cases, for example <code>_get_interface_def()</code> 
 898     and <code>_get_interface</code>, API are really not yet implemented.
 899     </UL>
 900 
 901 
 902 
 903 
 904 <H2>
 905 General Summary of Features or API Not Implemented in This Release:</H2>
 906 
 907 <UL>
 908 <LI>
 909 Interface Repository. An Interface Repository is not required for normal
 910 operation of Java IDL.
 911 
 912 <LI>
 913 Java IDL does not support <code>long double</code>.
 914 
 915 
 916 <LI>
 917 Policies (<code><a href="Policy.html">org.omg.CORBA.Policy</a></code>)
 918 and methods for getting them are not implemented.
 919 
 920 <LI>
 921 Domain managers (<code><a href="DomainManager.html">org.omg.CORBA.DomainManager</a></code>) and methods for
 922 getting them are not implemented.
 923 
 924 <LI>
 925 Service Information <code><a href="ServiceInformation.html">org.omg.CORBA.ServiceInformation</a></code>
 926 and ORB method 
 927 <code>public boolean get_service_information(short service_type, ServiceInformationHolder service_info)</code>
 928 are not implemented.
 929 
 930 <LI>ORB methods for supporting single-threading
 931 (<code>perform_work</code>, <code>work_pending</code>) are not implemented.
 932 
 933 <LI>IDL contexts.
 934 </UL>
 935 
 936 <HR>
 937 <H2>
 938 Specific List of Unimplemented Features in Package <code>org.omg.CORBA</code></H2>
 939 
 940 
 941 <H3>
 942 Unimplemented Methods in package <code>org.omg.CORBA</code>:</H3>
 943 
 944 <UL>
 945 <LI>
 946 <code>ORB</code>
 947 
 948 <UL>
 949 <LI>
 950 <code>public org.omg.CORBA.Policy create_policy(int type, org.omg.CORBA.Any val)</code>

 951 
 952 
 953 
 954 <LI>
 955 <code>public void perform_work()</code>
 956 
 957 <LI>
 958 <code>public boolean work_pending()</code>
 959 
 960 <LI>
 961 <code>public org.omg.CORBA.Current get_current()</code>
 962 
 963 <LI>
 964 <code>create_operation_list</code>
 965 
 966 <LI>
 967 <code>get_default_context</code>
 968 
 969 <LI>
 970 <code>get_service_information</code>
 971 
 972 <LI>
 973 obsolete <code>DynAnys</code> (deprecated in favor of <code>DynamicAny</code> package)
 974 
 975 
 976 </UL>
 977 
 978 
 979 
 980 </UL>
 981 @since JDK1.2
 982 @serial exclude
 983 </BODY>
 984 </HTML>
< prev index next >