Duta Dragos-Mihai

IDL value types mappings to Java differ depending on their definitions. Therefore, we have to differentiate three characteristics: - regular value types; - abstract value types; - boxed value types.

A regular value type is mapped to an abstract Java class of the same name, which, for each public state member of the value type, declares a corresponding public instance variable and, analogically, for private state members, declares corresponding protected instance variables. Normally, the class implements the interface org.omg.CORBA.portable.StreamableValue.

According to OMGs IDL to Java specification, an abstract value type is mapped to a Java interface, which, in turn, extends the interface org.omg.CORBA. portable.ValueBase. Recall that it is not possible to construct instances of an abstract value type. They are, rather, designated to be used solely as supertypes for regular value types, which can then be instantiated, or as supertypes for other abstract value types. The operations and attributes of an abstract value type are included in the Java interface using the normal rules.

There are two general cases to consider concerning the mapping of boxed value types: value types that are mapped to Javas primitive types and those that are mapped to Java classes. If the type contained in a boxed value type can be mapped to a primitive Java type (which concerns, e.g., the IDL types float, long, wchar, boolean, and octet), then, a Java class with the same name is created for this value type.

The data type any, which is the most flexible and powerful IDL type, is mapped to the Java class org.omg.CORBA.Any. This class implements the Java interface org.omg.CORBA.portable.IDLEntity and provides all the methods needed to insert instances of all Java counterparts of the pre-defined IDL types into an Any object (insert_<type>()) as well as to extract them from an Any object (extract_<type>()). For unsigned integer types, instead of the complete IDL keyword unsigned, only the letter u is prefixed. Table 10 below shows part of the methods declared in class Any.

The parameter passing semantics of IDL in parameters are call-by-value. Normal Java parameters are generated; the same holds for the return result of an IDL operation. Javas usual parameter passing mechanism is employed and the result of a Java method is returned as a result of the corresponding IDL operation. In the method itself, the argument may not be modified and the receiver may not retain a reference to the argument beyond the duration of the call.

IDL out and inout parameters define a call-by-result and combined call-by-value/result semantics, respectively. They cannot be passed directly with the standard Java mechanism. In these cases, the holder classes must be used instead. Suitable holder classes for pre-defined IDL data types are already supplied by the ORBs runtime library. Java objects that are used as arguments for an out parameter or that are returned as an invocation result are generated and owned by the receiver of the call. Once the call is completed, ownership of these objects migrates to the caller and the receiver may no longer utilize a reference to these objects. Otherwise, unexpected system behavior may result. For inout parameters, rules corresponding to those discussed for pure in parameters combined with those for out parameters apply in combination.

Attributes are mapped via accessor methods for getting and setting the attribute value; in the case of readonly attributes, only the get method is generated. For the two IDL attribute definitions : attribute unsigned long id; and readonly attribute string name; the IDL compiler generates three Java methods: int id() { // get method }; void id(int i) { // set method }; String name() { // get method only };

The mapping of an operation specified in IDL is the result of combining the diverse mapping rules for the single parts constituting the operation and were already addressed above. The operation name is built according to the mapping rules for identifiers. Return type and in parameters of the operation are mapped according to the rules for mapping data types. For inout and out parameters, the appropriate holder classes are utilized. The example below may, once more, exemplify this procedure: long notify(in string message, out unsigned long how_many); The Java method that is generated is int _notify(String message, IntHolder how_many) { ... };