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:
- All OMG IDL basic types
- All OMG IDL constructed types
- References to constants defined in OMG IDL
- Invocations of operations, including passing of parameters and receiving of result
- Access to attributes
9.2 Specialities in the Mapping
9.2.1 Names Reserved by the Compiler
The IDL compiler reserves all identifiers starting with
OE_andoe_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 long long long unsigned long long unsigned long long long char char wchar char boolean boolean octet octet string java.lang.String wstring java.lang.String any Any long double Not supported 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.
- The IDL Exceptions are not implemented in this Java mapping.
- The functions used for read/write to streams, defined in
Helperfunctions are named unmarshal (instead for read) and marshal (instead for write).
- The streams used in
Helperfunctions areOtpInputStreamfor input andOtpOutputStreamfor output.
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.javawhich 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.javaand 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,outorinout) 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.inoutparameters are not supported in the C mapping so if you are going to do calls to or from a C programinoutcannot be used in the IDL specifications.
outandinoutparameters must be of Holder types. There is a jar file (ic.jar) with Holder classes for the basic types in theicapplication. This library is in the directory$OTPROOT/lib/ic_<version number>/priv.9.10 Communication Toolbox
The generated client and server stubs use the classes defined in the
jinterfacepackage to communicate whith other nodes. The most important classes are :
OtpInputStreamwhich is the stream class used for incoming message storage
OtpOutputStreamwhich is the stream class used for outgoing message storage
OtpErlangPidwhich is the process identification class used to identify processes inside a java node.
The recommended constructor function for the OtpErlangPid isOtpErlangPid(String node, int id, int serial, int creation)where :
String node, is the name of the node where this process runs.
int id, is the identification number for this identity.
int serial, internal information, must be an 18-bit integer.
int creation, internal information, must have value in range 0..3.
OtpConnectionwhich is used to define a connection between nodes.
While the connection object is stub side constructed in client stubs, it is returned after calling theacceptfunction from an OtpErlangServer object in server stubs. The following methods used for node connection :
OtpInputStream receiveBuf(), which returns the incoming streams that contain the message arrived.
void sendBuf(OtpErlangPid client, OtpOutputStream reply), which sends a reply message (in an OtpOutputStream form) to the client node.
void close(), which closes a connection.
OtpServerwhich is used to define a server node.
The recommended constructor function for the OtpServer is :
The following methods used for node registration and connection acceptance :
OtpServer(String node, String cookie). where :
nodeis the requested name for the new java node, represented as a String object.
cookieis the requested cookie name for the new java node, represented as a String object.
boolean publishPort(), which registers the server node toepmddaemon.
OtpConnection accept(), which waits for a connection and returns the OtpConnection object which is unique for each client node.
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-back-ends :
- Standard java classes defined through OMG-IDL java mapping :
- Implementation-dependant classes :
- Erlang compatibility classes :
To use the Erlang build-in classes, you will have to include the file
- Pid, PidHelper, PidHolder
The Pid class originates fromOtpErlangPidand is used to represend the Erlang built-inpidtype, a process's identity. PidHelper and PidHolder are helper respectively holder classes for Pid.
- Ref, RefHelper, RefHolder
The Ref class originates fromOtpErlangRefand is used to represend the Erlang built-inreftype, an Erlang reference. RefHelper and RefHolder are helper respectively holder classes for Ref.
- Port, PortHelper, PortHolder
The Port class originates fromOtpErlangPortand is used to represend the Erlang built-inporttype, an Erlang port. PortHelper and PortHolder are helper respectively holder classes for Port.
- Term, TermHelper, TermHolder
The Term class originates fromAnyand is used to represend the Erlang built-intermtype, an Erlang term. TermHelper and TermHolder are helper respectively holder classes for Term.
erlang.idllocated under$OTPROOT/lib/ic/include.
9.12 The Term Class
The
Termclass is intended to represent the Erlang term generic type. It extends theAnyclass and it is basically used in the same way as in the Any type.The big difference between Term and Any is the use of
guardmethods instead ofTypeCodeto determine the data included in the Term. This is especially true when the Term's value class cannot be determinated at compilation time. The guard methods found in Term :
boolean isAtom()returnstrueif the Term is an OtpErlangAtom,falseotherwise
boolean isConstant()returnstrueif the Term is neither an OtpErlangList nor an OtpErlangTuple,falseotherwise
boolean isFloat()returnstrueif the Term is an OtpErlangFloat,falseotherwise
boolean isInteger()returnstrueif the Term is an OtpErlangInt,falseotherwise
boolean isList()returnstrueif the Term is an OtpErlangList,falseotherwise
boolean isString()returnstrueif the Term is an OtpErlangString,falseotherwise
boolean isNumber()returnstrueif the Term is an OtpErlangInteger or an OtpErlangFloat,falseotherwise
boolean isPid()returnstrueif the Term is an OtpErlangPid or Pid,falseotherwise
boolean isPort()returnstrueif the Term is an OtpErlangPort or Port,falseotherwise
boolean isReference()returnstrueif the Term is an OtpErlangRef,falseotherwise
boolean isTuple()returnstrueif the Term is an OtpErlangTuple,falseotherwise
boolean isBinary()returnstrueif the Term is an OtpErlangBinary,falseotherwise
9.13 Stub File Types
For each interface, three (3) stub/skeleton files are generated :
- A java interface file, named after the idl interface.
- A client stub file, named after the convention
_< interface name >Stubwhich implements the java interface. Example :_stackStub.java
- A server stub file, named after the convention
_< interface name >ImplBasewhich implements the java interface. Example :_stackImplBase.java
9.14 Client Stub Initialization, Methods Exported
The recommended constructor function for client stubs accepts four (4) parameters :
String selfNode, the node identification name to be used in the new client node.
String peerNode, the node identification name where the client process is running.
String cookie, the cookie to be used.
Object server, where the java Object can be one of:
OtpErlangPid, the server's process identity under the node where the server process is running.
String, the server's registered name under the node where the server process is running.
The methods exported from the generated client stub are :
void __disconnect(), which disconnects the server connection.
void __reconnect(), which disconnects the server connection if open, and then connects to the same peer.
void __stop(), which sends the standard stop termination call. When connected to an Erlang server, the server will be terminated. When connected to a java server, this will set a stop flag that denotes that the server must be terminated.
com.ericsson.otp.erlang.OtpErlangRef __getRef(), will return the message reference received from a server that denotes which call it is refering to. This is usefull when building asynchroinous clients.
java.lang.Object __server(), which returns the server for the current connection.
9.15 Server Skeleton Initialization, Server Stub Implementation, Methods Exported
The constructor function for server skeleton accepts no parameters.
The server skeleton file contains a server
switchwhich decodes messages from the input stream and calls implementation (callback) functions. As the server skeleton is declaredabstract, the application programmer will have to create a stub class thatextendsthe skeleton file. In this class, all operations defined in the interface class, generated under compiling the idl file, are implemented.The server skeleton file exports the following methods:
OtpOutputStrem invoke(OtpInputStream request), where the input streamrequestis unmarshalled, the implementation function is called and a reply stream is marshalled.
boolean __isStopped(), which returns true if a stop message is received. The implementation of the stub should always check if such a message is received and terminate if so.
boolean __isStopped(com.ericsson.otp.ic.Environment), which returns true if a stop message is received for a certain Environment and Connection. The implementation of the stub should always check if such a message is received and terminate if so.
OtpErlangPid __getCallerPid(), which returns the caller identity for the latest call.
OtpErlangPid __getCallerPid(com.ericsson.otp.ic.Environment), which returns the caller identity for the latest call on a certain Environment.
java.util.Dictionary __operations(), which returns the operation dictionary which holds all operations supported by the server skeleton.
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>/privand$OTPROOT/lib/jinterface_<version number>/privto yourCLASSPATHvariable to get basic Holder types and the communication classes.