[Erlang Systems]

9 IDL to Java language mapping

9.1 Introduction

This chapter describes the mapping of OMG IDL constructs to the Java programming language for the generation of native Java - Erlang communication.

This language mapping defines the following:

9.2 Specialities in the mapping

9.2.1 Names reserved by the compiler

The IDL compiler reserves all identifiers starting with OE_ and oe_ for internal use.

9.3 Basic OMG IDL types

The mapping of basic types are according to the standard. All basic types have a special Holder class.

OMG IDL type Java type
float float
double double
short short
unsigned short short
long int
unsigned long long
char char
boolean boolean
octet octet
any Any
Object Not supported
void void
OMG IDL basic types

9.4 Constructed OMG IDL types

All constructed types are according to the standard with three (3) major exceptions.

9.5 Mapping for constants

Constants are mapped according to the standard.

9.6 Invocations of operations

Operation invocation is implemented according to the standard. The implementation is in the class _<nterfacename>Stub.java which implements the interface in <nterfacename>.java. 

test._iStub client;

client.op(10);

9.6.1 Operation implementation

The server is implemented through extension of the class _<nterfacename>ImplBase.java and implementation of all the methods in the interface. 

public class server extends test._iImplBase {
  
  public void op(int i) throws java.lang.Exception {
    System.out.println("Received call op()");
    o.value = i;
    return i;
  }

}

9.7 Exceptions

While exception mapping is not implemented, the stubs will generate some Java exceptions in case of operation failure. No exceptions are propagated through the communication.

9.8 Access to attributes

Attributes are supported according to the standard.

9.9 Summary of argument/result passing for Java

All types (in, out or inout) of user defined parameters are supported in the Java mapping. This is also the case in the Erlang mappings but not in the C mapping. inout parameters are not supported in the C mapping so if you are going to do calls to or from a C program inout cannot be used in the IDL specifications.

out and inout parameters must be of Holder types. There is a jar file ( ic.jar) with Holder classes for the basic types in the ic application. This library is in the directory $OTPROOT/lib/ic_<version number>/priv.

9.10 Communication toolbox

The generated client and server stubs are using the classes defined in the jinterface package to communicate whith other nodes. Among other, the most important classes are :

9.11 The package com.ericsson.otp.ic

The package com.ericsson.otp.ic contains a number of java classes specially designed for the ic generated java-backends :

9.12 The Term class

The Term class is intended to represent the erlang term generic type. It extends the Any class and it is basically used the same way as the Any type does.

The big difference between Term and Any is the use of guard methods instead for TypeCode to determine the data included in the Term. This actual when cannot determine the Term's value class at compile time. The guard methods found in Term :

9.13 Stub file types

For each interface, three (3) stub/skeleton files are generated :

9.14 Client stub initialization, methods exported

The recommended constructor function for client stubs will take four (4) parameters :

The methods exported from the generated client stub are :

9.15 Server skeleton initialization, server stub implementation, methods exported

The constructor function for server skeleton will take no parameters.

The server skeleton file will contain a server switch which decodes messages from the input stream and calls implementation (callback) functions. As the server skeleton is declared abstract, the application programmer will have to create a stub class that extends the skeleton file. In this class, all operations defined in the interface class, generated under compiling the idl file, are implemented.

The server skeleton file will export the following methods :

9.16 A mapping example

This is a small example of a simple stack. There are two operations on the stack, push and pop. The example shows some of the generated files. 

// The source IDL file: stack.idl

struct s {
      long l;
      string s;
};

interface stack {
    void push(in s val);
    s pop();
};

When this file is compiled it produces eight files. Three important files are shown below.

The public interface is in stack.java. 

public interface stack {

/****
 * Operation "stack::push" interface functions 
 *
 */

    void push(s val) throws java.lang.Exception;

/****
 * Operation "stack::pop" interface functions 
 *
 */

    s pop() throws java.lang.Exception;

}

For the IDL struct s three files are generated, a public class in s.java. 

final public class s {
   // instance variables
   public int l;
   public java.lang.String s;

   // constructors
   public s() {};
   public s(int _l, java.lang.String _s) {
     l = _l;
     s = _s;
   };

};

A holder class in sHolder.java and a helper class in sHelper.java. The helper class is used for marshalling. 

public class sHelper {

   // constructors
   private sHelper() {};

   // methods
   public static s unmarshal(OtpInputStream in) 
      throws java.lang.Exception {
        :
        :
   };

   public static void marshal(OtpOutputStream out, s value) 
      throws java.lang.Exception {
        :
        :
   };

};

9.17 Running the compiled code

When using the generated java code you must have added $OTPROOT/lib/ic_<version number>/priv and $OTPROOT/lib/jinterface_<version number>/priv to your CLASSPATH variable to get basic Holder types and the communication classes.

Copyright © 1991-1999 Ericsson Utvecklings AB