0N/A <
META HTTP-
EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
0N/A <
META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en]C-gatewaynet (WinNT; U) 0N/A <
TITLE>package</
TITLE>
157N/A* Copyright (c) 1998, 2006, Oracle and/or its affiliates. All rights reserved. 0N/A* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A* This code is free software; you can redistribute it and/or modify it 0N/A* under the terms of the GNU General Public License version 2 only, as 157N/A* published by the Free Software Foundation. Oracle designates this 0N/A* particular file as subject to the "Classpath" exception as provided 157N/A* by Oracle in the LICENSE file that accompanied this code. 0N/A* This code is distributed in the hope that it will be useful, but WITHOUT 0N/A* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A* version 2 for more details (a copy is included in the LICENSE file that 0N/A* accompanied this code). 0N/A* You should have received a copy of the GNU General Public License version 0N/A* 2 along with this work; if not, write to the Free Software Foundation, 0N/A* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 157N/A* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 0N/A<
BODY BGCOLOR="#FFFFFF">
0N/AProvides the mapping of the OMG CORBA APIs to the Java<
SUP><
FONT 0N/ASIZE=-
2>TM</
FONT></
SUP>
0N/Aprogramming language, including the class <
TT>ORB</
TT>, which is implemented
0N/Aso that a programmer can use it as a fully-functional Object Request Broker
0N/A<
P>For a precise list of supported sections of official CORBA specifications with which
0N/Athe Java[TM] Platform, Standard Edition 6 complies, see <
A 0N/AJava[TM] SE 6</
em></
A>.
0N/A<
H1>General Information</
H1>
0N/AThe information in this section is information relevant to someone who
0N/Acompiles Interface Definition Language (IDL) files and uses the
0N/AORB to write clients and servers.
0N/A<
P>The classes and interfaces described in this section can be put into
0N/Afour groups: <
tt>ORB classes</
tt>, Exceptions, <
tt>Helper</
tt> classes,
0N/Aand <
tt>Holder</
tt> classes.
0N/AThe <
tt>ORB</
tt> Class</
H2>
0N/A<
P>An ORB handles (or brokers) method invocations between a client and
0N/Athe method's implementation on a server. Because the client and server
0N/Amay be anywhere on a network, and because the invocation and implementation
0N/Amay be written in different programming languages, an ORB does a great
0N/Adeal of work behind the scenes to accomplish this communication.
0N/A<
P>Most of what an ORB does is completely transparent to the user, and a major
0N/Aportion of the <
TT>CORBA</
TT> package consists of classes used by the ORB
0N/Abehind the scenes. The result is that most programmers will use only a
0N/Asmall part of this package directly. In fact, most programmers will use
0N/Aonly a few methods from the <
TT>ORB</
TT> class, some exceptions, and
0N/A<
TT>ORB</
TT> Methods</
H3>
0N/A<
P>Before an application can enter the CORBA environment, it must first:
0N/A<
LI>Be initialized into the ORB and possibly the object adapter (POA) environments.
0N/A<
LI>Get references to ORB object (for use in future ORB operations)
0N/Aand perhaps other objects (including the root POA or some Object Adapter objects).
0N/A<
P>The following operations are provided to initialize applications and obtain
0N/A the appropriate object references:
0N/A <
LI>Operations providing access to the ORB, which are discussed in this
0N/A <
LI>Operations providing access to Object Adapters, Interface Repository,
0N/A Naming Service, and other Object Services. These operations are described
0N/A in <
a href="#adv"><
em>Other Classes</
em></
a>.
0N/AWhen an application requires a CORBA environment it needs a mechanism to
0N/Aget an ORB object reference and possibly an OA object reference
0N/A(such as the root POA). This serves two purposes. First, it initializes
0N/Aan application into the ORB and OA environments. Second, it returns the
0N/AORB object reference and the OA object reference to the application
0N/Afor use in future ORB and OA operations.
0N/A<
P>In order to obtain an ORB object reference, applications call
0N/Athe <
tt>
ORB.init</
tt> operation. The parameters to the call can comprise an
0N/Aidentifier for the ORB for which the object reference is required,
0N/A and an arg_list, which is used to allow environment-specific data to be
0N/A passed into the call.
0N/A<
P>These are the <
TT>ORB</
TT> methods
0N/A that provide access to the ORB:
0N/A<
TT><
bold>init</
bold>()</
TT>
0N/A<
TT><
bold>init</
bold>(String [] args, Properties props)</
TT>
0N/A<
TT><
bold>init</
bold>(Applet app, Properties props)</
TT>
0N/A<
P>Using the <
tt>init()</
tt> method without parameters initiates
0N/Aa singleton ORB, which can only
0N/Agive typecode creation <
tt>any</
tt>s needed in code generated
0N/Ain Helper classes by <
tt>idlj</
tt>.
0N/A<
P>Applications require a portable means by which to obtain their
0N/Ainitial object references. References are required for the root
0N/APOA, POA Current, Interface Repository, and various Object Services
0N/Ainstances. The functionality required by the application is similar
0N/A to that provided by the Naming Service. However, the OMG does not
0N/A want to mandate that the Naming Service be made available to all
0N/A applications in order that they may be portably initialized.
0N/A Consequently, the operations shown in this section provide a
0N/A simplified, local version of the Naming Service that applications
0N/A can use to obtain a small, defined set of object references which
0N/A are essential to its operation. Because only a small well-defined
0N/A set of objects are expected with this mechanism, the naming context
0N/A can be flattened to be a single-level name space. This simplification
0N/A results in only two operations being defined to achieve the functionality
0N/A<
P>Initial references are obtained via two operations provided in
0N/Athe ORB object interface, providing facilities to list and
0N/Aresolve initial object references. These are:
0N/A<
TT><
bold>resolve_initial_references</
bold>(String name)</
TT>
0N/A<
TT><
bold>list_initial_services</
bold>()</
TT>
0N/A<
TT><
bold>register_initial_reference</
bold>(String id,
0N/A<
P>An example that uses some of these methods is <
A 0N/A<
em>Getting Started with Java IDL</
em></
A>.
0N/AExceptions in Java IDL are similar to those in any code written in the
0N/AJava programming language. If a method is defined to throw an exception,
0N/Athen any code using that method must have a <
TT>try</
TT>/<
TT>catch</
TT>
0N/Ablock and handle that exception when it is thrown.
0N/A<
P>The documentation on <
A 0N/AIDL exceptions</
em></
A> has more information and explains the difference between
0N/Asystem exceptions and user-defined exceptions.
0N/A<
P>The following is a list of the system exceptions (which are unchecked
0N/A BAD_CONTEXT
0N/A BAD_INV_ORDER
0N/A BAD_OPERATION
0N/A BAD_PARAM
0N/A BAD_TYPECODE
0N/A COMM_FAILURE
0N/A DATA_CONVERSION
0N/A FREE_MEM
0N/A IMP_LIMIT
0N/A INITIALIZE
0N/A INTERNAL
0N/A INTF_REPOS
0N/A INVALID_TRANSACTION
0N/A INV_FLAG
0N/A INV_IDENT
0N/A INV_OBJREF
0N/A INV_POLICY
0N/A MARSHAL
0N/A <
a href="#NO_IMPLEMENT">NO_IMPLEMENT</
a>
0N/A NO_MEMORY
0N/A NO_PERMISSION
0N/A NO_RESOURCES
0N/A NO_RESPONSE
0N/A OBJECT_NOT_EXIST
0N/A OBJ_ADAPTER
0N/A PERSIST_STORE
0N/A TRANSACTION_REQUIRED
0N/A TRANSACTION_ROLLEDBACK
0N/A TRANSIENT
0N/A UNKNOWN
0N/AThe following is a list of user-defined exceptions defined in the package
0N/A Bounds
0N/A UnknownUserException
0N/A WrongTransaction
0N/A PolicyError
0N/A <
H2>Subpackages</
H2>
0N/AThere are some packages inside the <
TT>CORBA</
TT> package with
0N/A"Package" as part of their names. These packages are generally quite small
0N/Abecause all they do is provide exceptions or classes for use by interfaces
0N/Aand classes in the <
TT>CORBA</
TT> package.
0N/Atwo exceptions thrown by methods in the class <
TT>TypeCode</
TT>. These
0N/A<
TT>InconsistentTypeCode</
TT>
0N/A<
P>Another package that is a subpackage of <
tt>CORBA</
tt> is the <
tt>
0N/Aprovides a set of ORB APIs that makes it
0N/Apossible for code generated by one vendor's IDL compiler to run
0N/Aon another vendor's ORB.
0N/A<
P>Support for out and inout parameter passing modes requires the use of
0N/Aclasses</
a></
em>. Because the Java programming language does not support out or
0N/Ainout parameters, holder classes are needed as a means of passing a parameter
0N/Athat can be modified. To support portable stubs and skeletons, holder classes also implement
0N/A <
P>Holder classes are named by appending "Holder" to the name of the type.
0N/A The name of the type refers to its name in the Java programming language. For
0N/A example, a holder class for the interface named <
tt>Account</
tt> in the Java programming
0N/A language would be named <
tt>AccountHolder</
tt>.
0N/A<
P>Holder classes are available for all of the basic IDL
0N/A there are already-defined classes for <
tt>LongHolder</
tt>, <
tt>ShortHolder</
tt>,
0N/A <
tt>FloatHolder</
tt>, and so on. Classes are also generated for
0N/A all named user-defined IDL types except those defined by <
tt>typedefs</
tt>.
0N/A (Note that in this context user defined includes types that are
0N/A defined in OMG specifications such as those for the Interface
0N/A Repository, and other OMG services.)
0N/A<
P>Each holder class has:
0N/A<
LI>a constructor from an instance
0N/A<
LI>a default constructor
0N/A<
LI>a public instance member, <
tt>value</
tt> which is the typed value.
0N/A<
LI>a method for reading an input stream and assigning the contents to the
0N/Atype's <
tt>value</
tt> field
0N/A<
LI>a method for writing the value of the <
tt>value</
tt> field to an output stream
0N/A<
LI>a method for getting the typecode of the type
0N/A<
P>The default constructor sets the value field to the default value for the
0N/Atype as defined by the Java language:
0N/A<
LI><
tt>false</
tt> for boolean
0N/A<
LI><
tt>0</
tt> for numeric and char types
0N/A<
LI><
tt>null</
tt> for strings and object references
0N/AAs an example, if the interface <
code>Account</
code>, defined in OMG IDL,
0N/Awere mapped to the Java programming language, the following holder class
0N/Apublic final class AccountHolder implements
0N/A // field that holds an Account object
0N/A public Account value = null;
0N/A // default constructor
0N/A public AccountHolder ()
0N/A // creates a new AccountHolder from initialValue
0N/A public AccountHolder (Account initialValue)
0N/A value = initialValue;
0N/A // reads the contents of i and assigns the contents to value
0N/A // writes value to o
0N/A // returns the typecode for Account
0N/A<
P>For more information on Holder classes, see Chapter 1.4, <
em>Mapping for
0N/A<
em>OMG IDL to Java Language Mapping</
em></
a>. The Holder classes defined
0N/A <
TT>AnyHolder
0N/A</
TT> <
TT>AnySeqHolder
0N/A</
TT> <
TT>BooleanHolder
0N/A</
TT> <
TT>BooleanSeqHolder
0N/A</
TT> <
TT>ByteHolder
0N/A</
TT> <
TT>CharHolder
0N/A</
TT> <
TT>CharSeqHolder
0N/A</
TT> <
TT>CurrentHolder
0N/A</
TT> <
TT>DoubleHolder
0N/A</
TT> <
TT>DoubleSeqHolder
0N/A</
TT> <
TT>FixedHolder
0N/A</
TT> <
TT>FloatHolder
0N/A</
TT> <
TT>FloatSeqHolder
0N/A</
TT> <
TT>IntHolder
0N/A</
TT> <
TT>LongHolder
0N/A</
TT> <
TT>LongLongSeqHolder
0N/A</
TT> <
TT>LongSeqHolder
0N/A</
TT> <
TT>ObjectHolder
0N/A</
TT> <
TT>OctetSeqHolder
0N/A</
TT> <
TT>ParameterModeHolder
0N/A</
TT> <
TT>PolicyErrorHolder
0N/A</
TT> <
TT>PolicyListHolder
0N/A</
TT> <
TT>PrincipalHolder
0N/A</
TT> <
TT>ServiceInformationHolder
0N/A</
TT> <
TT>ShortHolder
0N/A</
TT> <
TT>ShortSeqHolder
0N/A</
TT> <
TT>StringHolder
0N/A</
TT> <
TT>StringSeqHolder
0N/A</
TT> <
TT>TypeCodeHolder
0N/A</
TT> <
TT>ULongLongSeqHolder
0N/A</
TT> <
TT>ULongSeqHolder
0N/A</
TT> <
TT>UnknownUserExceptionHolder
0N/A</
TT> <
TT>UShortSeqHolder
0N/A</
TT> <
TT>ValueBaseHolder
0N/A</
TT> <
TT>WCharSeqHolder
0N/A</
TT> <
TT>WrongTransactionHolder
0N/A</
TT> <
TT>WStringSeqHolder</
TT>
0N/A<
h2>Helper Classes </
h2>
0N/A<
P>Helper files supply several static methods needed to manipulate the type.
0N/A <
LI><
tt>Any</
tt> insert and extract operations for the type
0N/A <
LI>getting the repository id
0N/A <
LI>getting the typecode
0N/A <
LI>reading and writing the type from and to a stream
0N/A <
LI>implement the <
code>ValueHelper</
code> interface (if it is a user-defined
0N/A<
P>The helper class for a mapped IDL interface or abstract interface
0N/A also include narrow operation(s). The static narrow method allows
0N/A is thrown if the narrow fails because the object reference does not
0N/A support the requested type. A different system exception is raised
0N/A to indicate other kinds of errors. Trying to narrow a <
tt>null</
tt> will always
0N/A succeed with a return value of <
tt>null</
tt>. Generally, the only helper method an application programmer uses is
0N/Athe <
code>narrow</
code> method. The other methods are normally used behind
0N/Athe scenes and are transparent to the programmer.
0N/Afall into two broad categories, <
a href="#value">helpers for value types</
a> and
0N/A<
a href="#basic">helpers for non value types</
a>. Because all of the helper
0N/Aclasses in one category
0N/Aprovide the same methods, one generic explanation of each
0N/Acategory of helper classes is presented here.
0N/AWhen OMG IDL is mapped to the Java programming language,
0N/Aa "helper" class is generated for each user-defined type.
0N/AThis generated class will have the name of the user-defined type with
0N/Athe suffix <
code>Helper</
code> appended. For example, if the
0N/Ainterface <
code>Account</
code> is defined in OMG IDL, the
0N/A<
code>idlj</
code> compiler will automatically generate a class named
0N/A<
code>AccountHelper</
code>. The <
code>AccountHelper</
code> class
0N/Awill contain the static methods needed for manipulating instances of the type,
0N/Ain this case, <
code>Account</
code> objects.
0N/A<
a name="narrow"></
a>
0N/A<
h3>The <
code>narrow</
code> Method</
h3>
0N/AWhen an object is the return value for a method, it is returned in the
0N/Amore specific type before it can be operated on. For example, an
0N/A<
code>Account</
code> object will be returned as a generic object and must
0N/Abe narrowed to an <
code>Account</
code> object so that <
code>Account</
code>
0N/Amethods may be called on it.
0N/AThe <
code>narrow</
code> method has two forms, one that takes an
0N/Anot determines which <
code>narrow</
code> method its helper class will provide.
0N/AThe helper class for an interface
0N/Athat is not abstract will have a <
code>narrow</
code> method that takes a CORBA
0N/Aobject, whereas the <
code>narrow</
code> method for an interface that is abstract
0N/Atake an object in the Java programming language. The helper class for a
0N/Anon-abstract interface that has at least one abstract base interface will provide
0N/Aboth versions of the <
code>narrow</
code> method.
0N/Atutorial uses a <
tt>narrow</
tt> method that looks
0N/A // create and initialize the ORB
0N/A // get the root naming context
0N/A // Use NamingContextExt instead of NamingContext. This is
0N/A // part of latest Inter-Operable naming Service.
0N/A // resolve the Object Reference in Naming
0N/A String name = "Hello";
0N/A<
h3>Example of a Basic Helper Class</
h3>
0N/AA basic helper class, for purposes of this explanation, is one with
0N/Athe methods that are provided by every helper class, plus a <
code>narrow</
code>
0N/Amethod if the type defined in OMG IDL maps to an interface in the Java
0N/Aprogramming language. Types that are not value types will have a basic
0N/Ahelper class generated for them.
0N/AFor example, assuming that the interface <
code>Account</
code> is not a
0N/Avalue type IDL type and is also not an abstract interface and has no
0N/Aabstract base interfaces, its <
code>AccountHelper</
code> class will look
0N/Aabstract public class AccountHelper
0N/A private static String _id = "IDL:Account:1.0";
0N/A // inserts an Account object into an Any object
0N/A // extracts an Account object from an Any object
0N/A // gets the typecode for this type
0N/A if (__typeCode == null)
0N/A // gets the repository id for this type
0N/A public static String id ()
0N/A // reads an Account object from an input stream
0N/A // writes an Account object to an outputstream
0N/A // converts (narrows) an Object to an Account object
0N/A else if (obj instanceof Account)
0N/A return (Account)obj;
0N/A else if (!obj._is_a (id ()))
0N/A _AccountStub stub = new _AccountStub ();
0N/A stub._set_delegate(delegate);
0N/A<
h3>Value Type Helper Classes</
h3>
0N/AA helper class for a value type includes different renderings of
0N/Athe same methods generated for non-value type methods. The main difference
0N/A is that value types are types that can be
0N/Apassed by value as parameters or return values of a method, which means that
0N/Athey must be serializable.
0N/A<
P>Assuming that <
code>Address</
code> is a value type, the
0N/A<
code>AddressHelper</
code> class will look like this:
0N/Aabstract public class AddressHelper
0N/A private static String _id = "IDL:Address:1.0";
0N/A // same as for non-value type
0N/A // same as for non-value type
0N/A private static boolean __active = false;
0N/A // getting the typecode for the type
0N/A if (__typeCode == null)
0N/A if (__typeCode == null)
0N/A // same as for non-value type
0N/A public static String id ()
0N/A // reads a serializable instance of Address from the given input stream
0N/A // writes a serializable instance of Address to the given output stream
0N/A<
P>The Helper classes defined in the package <
TT>
org.
omg.
CORBA</
TT> are:
0N/A <
TT>AnySeqHelper
0N/A</
TT> <
TT>BooleanSeqHelper
0N/A</
TT> <
TT>CharSeqHelper
0N/A</
TT> <
TT>CompletionStatusHelper
0N/A</
TT> <
TT>CurrentHelper
0N/A</
TT> <
TT>DefinitionKindHelper
0N/A</
TT> <
TT>DoubleSeqHelper
0N/A</
TT> <
TT>FieldNameHelper
0N/A</
TT> <
TT>FloatSeqHelper
0N/A</
TT> <
TT>IdentifierHelper
0N/A</
TT> <
TT>IDLTypeHelper
0N/A</
TT> <
TT>LongLongSeqHelper
0N/A</
TT> <
TT>LongSeqHelper
0N/A</
TT> <
TT>NameValuePairHelper
0N/A</
TT> <
TT>ObjectHelper
0N/A</
TT> <
TT>OctetSeqHelper
0N/A</
TT> <
TT>ParameterModeHelper
0N/A</
TT> <
TT>PolicyErrorCodeHelper
0N/A</
TT> <
TT>PolicyErrorHelper
0N/A</
TT> <
TT>PolicyHelper
0N/A</
TT> <
TT>PolicyListHelper
0N/A</
TT> <
TT>PolicyTypeHelper
0N/A</
TT> <
TT>RepositoryIdHelper
0N/A</
TT> <
TT>ServiceDetailHelper
0N/A</
TT> <
TT>ServiceInformationHelper
0N/A</
TT> <
TT>SetOverrideTypeHelper
0N/A</
TT> <
TT>ShortSeqHelper
0N/A</
TT> <
TT>StringSeqHelper
0N/A</
TT> <
TT>StringValueHelper
0N/A</
TT> <
TT>StructMemberHelper
0N/A</
TT> <
TT>ULongLongSeqHelper
0N/A</
TT> <
TT>ULongSeqHelper
0N/A</
TT> <
TT>UnionMemberHelper
0N/A</
TT> <
TT>UnknownUserExceptionHelper
0N/A</
TT> <
TT>UShortSeqHelper
0N/A</
TT> <
TT>ValueBaseHelper
0N/A</
TT> <
TT>ValueMemberHelper
0N/A</
TT> <
TT>VersionSpecHelper
0N/A</
TT> <
TT>VisibilityHelper
0N/A</
TT> <
TT>WCharSeqHelper
0N/A</
TT> <
TT>WrongTransactionHelper
0N/A</
TT> <
TT>WStringSeqHelper
0N/A</
TT> <
TT>WStringValueHelper</
TT>
0N/AThe other classes and interfaces in the <
TT>CORBA</
TT> package, which are
0N/Aused behind the scenes, can be put into four groups. Three of the groups
0N/Aare used with requests in some capacity, and the fourth group, concerning
0N/Athe Interface Repository, is a category by itself.
0N/AClasses Created by an ORB</
H2>
0N/AThe first group contains classes that are created by an ORB and contain
0N/Ainformation used in request operations.
0N/A<
TT>TCKind</
TT> -- indicates the kind (datatype) for a <
TT>TypeCode</
TT>
0N/A<
TT>TypeCode</
TT> -- indicates a datatype and possibly other information
0N/A<
TT>Any</
TT> -- contains a value and its typecode
0N/A<
TT>NamedValue</
TT> -- contains a name, an <
TT>Any</
TT> object, and an
0N/Aargument mode flag. <
TT>NamedValue</
TT> objects contain information about
0N/Amethod arguments, method return values, or a context.
0N/A<
TT>ContextList</
TT> -- a list of strings that describe the contexts that
0N/Aneed to be resolved and sent with an invocation
0N/A<
TT>ExceptionList</
TT> -- a list of <
TT>TypeCode</
TT>s for exceptions that
0N/Amay be thrown by a method
0N/A<
TT>Environment</
TT> -- a container for the exception thrown during a method
0N/A<
TT>Context</
TT> -- a list of <
TT>NamedValue</
TT> objects used to pass
0N/Aauxiliary information from client to server
0N/A<
TT>NVList</
TT> -- a list of <
TT>NamedValue</
TT> objects, used to pass
0N/Aarguments or get results
0N/AClasses That Deal with Requests</
H2>
0N/AThe second group of classes deals with requests:
0N/A<
TT>Object</
TT> -- the base class for all CORBA object references
0N/A<
TT>Request</
TT> -- the main class in the DII, which contains methods for
0N/Aadding arguments to the request, for accessing information about the method
0N/Abeing invoked (the method name, its arguments, exceptions it throws, and
0N/Aso on), and for making invocations on the request
0N/A<
TT>DynamicImplementation</
TT> -- the base class for server implementations
0N/Ausing the DSI. It has the method <
TT>invoke</
TT>, which is used by an
0N/Aof this class to determine the state of a <
TT>ServerRequest</
TT> object
0N/Aand to set its result or exception
0N/A<
TT>ServerRequest</
TT> -- captures the explicit state of a request for
0N/Athe Dynamic Skeleton Interface
0N/AInterfaces That Serve as Constants</
H2>
0N/AThe third group contains interfaces that serve as constants. The IDL-to-Java
0N/Amapping mandates that IDL enums are mapped to a Java class with the enumerated
0N/Avalues represented as public static final fields in that class (
e.g. 0N/AOn the other hand IDL constants defined outside of an IDL interface are
0N/Amapped to a Java interface for each constant.
0N/A<
P>This is why several interfaces in the <
TT>
org.
omg.
CORBA</
TT> package
0N/Aconsist of a single field, <
TT>value</
TT>, which is a <
TT>short</
TT>. This
0N/Afield is a constant used for such things as an error code or value modifier.
0N/AFor example, the <
TT>value</
TT> field of the interface <
TT>BAD_POLICY</
TT>
0N/Ais one of the possible reasons for the exception <
TT>PolicyError</
TT> to
0N/A<
P>The exception <
TT>PolicyError</
TT> uses the <
TT>value</
TT> field of
0N/Athe following interfaces as its possible error codes.
0N/A<
TT>BAD_POLICY_TYPE</
TT>
0N/A<
TT>BAD_POLICY_VALUE</
TT>
0N/A<
TT>UNSUPPORTED_POLICY</
TT>
0N/A<
TT>UNSUPPORTED_POLICY_VALUE</
TT>
0N/Aof one of the following interfaces. The <
TT>VM</
TT> in the names of these
0N/Ainterfaces stands for "value modifier."
0N/A<
TT>VM_TRUNCATABLE</
TT>
0N/AThe following constants are returned by a <
code>ValueMember</
code> object's
0N/Aaccess method to denote the visibility of the <
code>ValueMember</
code> object.
0N/A<
TT>PRIVATE_MEMBER</
TT>
0N/A<
TT>PUBLIC_MEMBER</
TT>
0N/AThese flags, used in <
TT>NamedValue</
TT> objects or as parameters to methods,
0N/Aare defined in the following interfaces:
0N/A<
TT>CTX_RESTRICT_SCOPE</
TT>
0N/AInterface Repository Interfaces and Classes</
H2>
0N/AA fourth group contains the Interface Repository interfaces and classes,
0N/Awhich are generated by the <
TT>idlj</
TT> compiler from the OMG IDL
0N/Ainterface <
TT>
ir.idl</
TT>. The purpose of the Interface Repository is to
0N/Aidentify the interfaces stored in it so that they can be accessed by an
0N/AORB. Each module, type, interface, attribute, operation, parameter, exception,
0N/Aconstant, and so on is described completely by the Interface Repository
0N/A<
P>An ORB does not require that there be an interface repository, and Java
0N/AIDL does not include one. Even though this release does not include an
0N/Aimplementation of an interface repository, the following IR classes and
0N/Ainterfaces have been included for the purpose of creating typecodes (see
0N/Acreate_value_tc, create_struct_tc, create_union_tc and create_exception_tc
0N/A<!-- End Page Data --> 0N/ARelated Documentation</
H1>
0N/AFor overviews, guides, and a tutorial, please see:
0N/A<
P><
A NAME="unimpl"></
A>
0N/ACORBA Features Not Implemented in Java IDL</
H1>
0N/A<
P>Some of the API included in <
TT>
org.omg</
TT> subpackages is provided for
0N/Aconformance with the current OMG CORBA specification but is not implemented
0N/Ain Sun's release of the JDK<
SUP><
FONT SIZE=-
2>TM</
FONT></
SUP>. This enables
0N/Aother JDK licensees to provide implementations of this API in standard
0N/Aextensions and products.
0N/A<
P><
A NAME="NO_IMPLEMENT"></
A>
0N/A<
h2>Features That Throw NO_IMPLEMENT</
h2>
0N/A<
P>Some of the API included in <
TT>
org.omg</
TT> subpackages throw
0N/A<
tt>NO_IMPLEMENT</
tt> exceptions for various reasons. Among these reasons
0N/A <
LI>In some cases, for example <
tt>LocalObject</
tt>, the complete
0N/A implementation according to the specification indicates that
0N/A these API should throw <
tt>NO_IMPLEMENT</
tt>.
0N/A <
LI>In most cases, for example methods in <
tt>
ORB.java</
tt>,
0N/A <
tt>NO_IMPLEMENT</
tt> are actually implemented in subclasses
0N/A elsewhere in the ORB code.
0N/A <
LI>In some cases, for example <
tt>_get_interface_def()</
tt>
0N/A and <
tt>_get_interface</
tt>, API are really not yet implemented.
0N/AGeneral Summary of Features or API Not Implemented in This Release:</
H2>
0N/AInterface Repository. An Interface Repository is not required for normal
0N/Aoperation of Java IDL.
0N/AJava IDL does not support <
TT>long double</
TT>.
0N/Agetting them are not implemented.
0N/AServiceInformationHolder
0N/Aservice_info)</
TT> are not implemented.
0N/A<
LI>ORB methods for supporting single-threading (<
tt>perform_work</
tt>, <
tt>work_pending</
tt>) are not implemented.
0N/ASpecific List of Unimplemented Features in Package <
TT>
org.
omg.
CORBA</
TT></
H2>
0N/A<
TT>public void perform_work()</
TT>
0N/A<
TT>public boolean work_pending()</
TT>
0N/A<
TT>create_operation_list</
TT>
0N/A<
TT>get_default_context</
TT>
0N/A<
TT>get_service_information</
TT>
0N/Aobsolete <
TT>DynAnys</
TT> (deprecated in favor of <
tt>DynamicAny</
tt> package)