Provides the mapping of the OMG CORBA APIs to the JavaTM programming language, including the class ORB, which is implemented so that a programmer can use it as a fully-functional Object Request Broker (ORB).

An ORB handles (or brokers) method invocations between a client and the method's implementation on a server. Because the client and server may be anywhere on a network, and because the invocation and implementation may be written in different programming languages, an ORB does a great deal of work behind the scenes to accomplish this communication.

What the General User Needs to Know

Most of what an ORB does is completely transparent to the user, and a major portion of the CORBA package consists of classes used by the ORB behind the scenes. The result is that most programmers will use only a small part of this package directly. In fact, most programmers will use only a few methods from the ORB class, some exceptions, and occasionally, a holder class.

ORB Methods

These are the ORB methods that a general user might invoke:

Exceptions

Exceptions in Java IDL are similar to those in any code written in the Java programming language. If a method is defined to throw an exception, then any code using that method must have a try/catch block and handle that exception when it is thrown.

The documentation on Java IDL exceptions has more information and explains the difference between system exceptions and user-defined exceptions.

The following is a list of the system exceptions (which are unchecked exceptions inheriting through org.omg.CORBA.SystemException from java.lang.RuntimeException) that are defined in the package org.omg.CORBA: 

 
        BAD_CONTEXT
        BAD_INV_ORDER
        BAD_OPERATION
        BAD_PARAM
        BAD_TYPECODE
        COMM_FAILURE
        DATA_CONVERSION
        FREE_MEM
        IMP_LIMIT
        INITIALIZE
        INTERNAL
        INTF_REPOS
        INVALID_TRANSACTION
        INV_FLAG
        INV_IDENT
        INV_OBJREF
        INV_POLICY
        MARSHAL
        NO_IMPLEMENT
        NO_MEMORY
        NO_PERMISSION
        NO_RESOURCES
        NO_RESPONSE
        OBJECT_NOT_EXIST
        OBJ_ADAPTER
        PERSIST_STORE
        TRANSACTION_REQUIRED
        TRANSACTION_ROLLEDBACK
        TRANSIENT
        UNKNOWN
The following is a list of user-defined exceptions defined in the package org.omg.CORBA. 
 
        Bounds
        UnknownUserException
        WrongTransaction 
        PolicyError
Note that there are some packages inside the CORBA package with "Package" as part of their names. These packages are generally quite small because all they do is provide exceptions or classes for use by interfaces and classes in the CORBA package.

For example, the package org.omg.CORBA.TypeCodePackage contains two exceptions thrown by methods in the class TypeCode. These exceptions are:

The package org.omg.CORBA.ORBPackage contains two exceptions: The package org.omg.CORBA.DynAnyPackage contains four exceptions:

Holder classes

Operations in an IDL interface may take out or inout parameters as well as in parameters. The Java programming language only passes parameters by value and thus does not have out or inout parameters, so these are mapped to what are called Holder classes. In place of the IDL out parameter, the Java programming language method will take an instance of the Holder class of the appropriate type. The result that was assigned to the out or inout parameter in the IDL interface is assigned to the value field of the Holder class.

The package org.omg.CORBA contains a Holder class for each of the basic types (BooleanHolder, LongHolder, StringHolder, and so on). It also has Holder classes for each generated class (such as TypeCodeHolder), but these are used transparently by the ORB, and the programmer usually does not see them.

The Holder classes defined in the package org.omg.CORBA are: 

     AnyHolder
     BooleanHolder
     ByteHolder
     CharHolder
     DoubleHolder
     FloatHolder
     FixedHolder
     IntHolder
     LongHolder
     ObjectHolder
     PrincipalHolder
     ShortHolder
     StringHolder
     TypeCodeHolder

For Advanced Users

The other classes and interfaces in the CORBA package, which are used behind the scenes, can be put into four groups. Three of the groups are used with requests in some capacity, and the fourth group, concerning the Interface Repository, is a category by itself.

Classes Created by an ORB

The first group contains classes that are created by an ORB and contain information used in request operations. They are listed in roughly increasing order of complexity:

Classes That Deal with Requests

The second group of classes deals with requests:

Interfaces That Serve as Constants

The third group contains interfaces that serve as constants. The IDL-to-Java mapping mandates that IDL enums are mapped to a Java class with the enumerated values represented as public static final fields in that class (e.g. DefinitionKind). On the other hand IDL constants defined outside of an IDL interface are mapped to a Java interface for each constant.

This is why several interfaces in the org.omg.CORBA package consist of a single field, value, which is a short. This field is a constant used for such things as an error code or value modifier. For example, the value field of the interface BAD_POLICY is one of the possible reasons for the exception PolicyError to be thrown. To specify this error code, you would use BAD_POLICY.value.

The exception PolicyError uses the value field of the following interfaces as its possible error codes.

The method TypeCode.type_modifier returns the value field of one of the following interfaces. The VM in the names of these interfaces stands for "value modifier." The following constants are returned by ValueMembers access method to denote the visibility of the ValueMember These flags, used in NamedValue objects or as parameters to methods, are defined in the following interfaces:

Interface Repository Interfaces and Classes

A fourth group contains the Interface Repository interfaces and classes, which are generated by the idltojava compiler from the OMG IDL interface ir.idl. The purpose of the Interface Repository is to identify the interfaces stored in it so that they can be accessed by an ORB. Each module, type, interface, attribute, operation, parameter, exception, constant, and so on is described completely by the Interface Repository API.

An ORB does not require that there be an interface repository, and Java IDL does not include one. Even though this release does not include an implementation of an interface repository, the following IR classes and interfaces have been included for the purpose of creating type codes (see create_value_tc, create_struct_tc, create_union_tc and create_exception_tc methods in interface org.omg.CORBA.ORB)
 

Related Documentation

For overviews, guides, and a tutorial, please see:

CORBA Features Not Implemented in Java IDL

Some of the API included in org.omg.CORBA is provided for conformance with the current OMG CORBA specification but is not implemented in Sun's release of the JDKTM. This enables other JDK licensees to provide implementations of this API in standard extensions and products.

General Summary of Features or API Not Implemented in This Release:

Specific List of Unimplemented Features in Package org.omg.CORBA

Unimplemented Interfaces in package org.omg.CORBA:

Unimplemented Methods in package org.omg.CORBA:

@since JDK1.2