122.

  

CORBA to Java Mapping

CORBA has bindings to a number of languages. That is, there is a translation from IDL to each language, and there is a runtime environment that supports objects written in these languages. A recent addition is Java, and this binding is still under active development (that is, the core is basically settled, but some parts are still changing). This binding must cover all elements of IDL. Here is a horribly brief summary of the CORBA translations:

• Module ” A module is translated to a Java package. All elements within the module becomes classes or interfaces within the package.

• Basic types ” Most of the basic types map in a straightforward manner ”a CORBA int becomes a Java int , a CORBA string becomes a Java java.lang.String , and so on. Some are a little tricky, such as the unsigned types, which have no Java equivalent.

• Constant ” Constants within a CORBA IDL interface are mapped to constants within the corresponding Java interface. Constants that are "global" have no direct equivalent in Java, and so are mapped to Java interfaces with a single field that is the value.

• Enum ” Enumerated types have no direct Java equivalent, and so are mapped into a Java interface with the enumeration as a set of integer constants.

• Struct ” A CORBA IDL structure is implemented as a Java class with instance variables for all fields.

• Interface ” A CORBA IDL interface translates into a Java interface.

• Exception ” A CORBA IDL exception maps to a final Java class.

This mapping does not conform to naming conventions, such as those established for Java Beans. For example, the IDL declaration readonly string purpose becomes the Java accessor method String purpose() rather than String getPurpose() . Where Java code is generated, the generated names will be used, but in methods that I write, I will use the more accepted naming forms.