IDL-to-Java mapping: Part One

• 所有的 IDL 基本数据类型
• 所有的 IDL 结构数据类型
• IDL 中定义的常量
• IDL 中定义的对象引用
• 对操作的调用，包括传递参数和接收结果
• 异常，包括当操作产生异常时的处理和访问异常参数的方法
• 属性访问
• ORB 定义的操作符号，如动态调用接口，对象适配器等等。

一个完整的语言映射允许程序员以对于某种特定编程语言来说很便捷的方式来访问所有的ORB 功能。为了支持源代码的可移植性，所有的 ORB实现都要支持某种语言的同一映射。

MotherIDL
在本文中将使用一个叫做 MotherIDL 的文件-- motheridl.idl 。以上要求这一 IDL文件都可以做到，它的目的就是示意并检验部分映射。你最好先浏览它一下，这样我们逐步讲述的时候你就会对它比较熟悉了。

以 motheridl.idl 为例，你将在 IDL文件中看到如下结构：

module corbasem {
  module gen {
    module motheridl {
      module holderexample {
      ...
      };
      module conflicts {
      ...
      };
      module basictypes {
      ...
      };
      module constructedtypes {
      ...
      };
      module holderexample2 {
      ...
      };
      module MI {
      ...
      };
      module MI2 {
      ...
      };
    };    
  };
};
                

这转换为以下的目录结构：

E:\_work\TICORBA\Projects\corbasem\gen\motheridl>dir /AD /S
 Volume in drive E has no label.
 Volume Serial Number is B415-7161
Directory of E:\_work\TICORBA\Projects\corbasem\
07/15/2000  01:41p      <DIR>          .
07/15/2000  01:41p      <DIR>          ..
               0 File(s)              0 bytes
Directory of E:\_work\TICORBA\Projects\corbasem\gen
07/15/2000  01:41p      <DIR>          .
07/15/2000  01:41p      <DIR>          ..
               0 File(s)              0 bytes
Directory of E:\_work\TICORBA\Projects\corbasem\gen\motheridl
07/15/2000  01:41p      <DIR>          .
07/15/2000  01:41p      <DIR>          ..
07/15/2000  01:41p      <DIR>          basictypes
07/15/2000  01:41p      <DIR>          conflicts
07/15/2000  01:41p      <DIR>          constructedtypes
07/15/2000  01:41p      <DIR>          holderexample
07/15/2000  01:41p      <DIR>          holderexample2
07/15/2000  01:41p      <DIR>          MI
07/15/2000  01:41p      <DIR>          MI2
               0 File(s)              0 bytes
                

将 IDL 映射为 Java元素的一个基本思想是一致性。如同其它任何类库一样，它们必须存在稳定性，也就是说在修改库中的类时不必删除现有的方法；不改变接口。CORBA在这方面应该做的更好，因为多个 ORB提供商将要使用这一映射来生成类库。我们希望在不同 ORB实现之间有着一致性；这意味着可移植性。如果 ORB 提供商A的 IDL 到Java 映射在 org.VendA.Excep 的 package 中提供了UserException ，而提供商B在 org.VendB.UtilTypes 的package中也提供了相同的 UserException ，Client 或 Server的代码将不能够移植。Client 或 Server 移动到另一个 ORB时需要改变代码并重新编译。这可不是我们选择 CORBA的原因！我们希望并要求可移植性；因此 OMG 规定了库结构。

在 Java 编程语言中，关键词 package 将 Java类组成类库，并控制对类库中的构件的访问。我们的 Java 类库中将包含Java 编程语言中需要编译的所有素材，这些我们已经在 IDL中描述过了。但是为了不同提供商的类库之间的可移植性，必须定义类库结构或者类库包，并且严格遵守这些定义。只有这样Client才能依赖于代码并且保证不用在不同提供商的ORB之间移植时重写代码。

在 IDL 到 Java 映射的可移植性部分中规定了API，它提供了库结构和最小功能集，使 JavaORB中可以使用可移植的存根和骨架。因为 Java类经常被下载，它们往往来自独立于ORB提供商的代码，因此对于 Java编程语言的互操作性需求就超过了其它语言。出于这些原因，定义存根和骨架使用的接口是最基本的要求。如果这些结构不加以定义的话，存根（或骨架）的使用将需要一个或两个方案。一个要求由IDL 到 Java编译器或ORB提供商提供的类似工具（或者与ORB所使用的兼容）生成存根（或骨架），以使生成的存根能够适合ORB提供商的类库结构，另一个方案要求下载存根或骨架时同时下载整个ORB运行时环境。我们不希望采用这两种方案中的任何一个。理想的情况是将IDL 发送到 Client 端或者由 Client 下载，利用 Client端选择的工具生成存根，并从它们的环境连接到我们的 Server。

因此，Java 语言映射高度依赖于标准的结构，它在一套标准的 Java包中实现 -- org.omg.* 。IDL 到 Java映射中重要的一项就是包含PIDL，本地类型和ORB可移植接口的压缩文件。它给出了包中确切内容的定义性声明。当然，如同这一行中的其它任何事一样，在不远的将来IDL 到 Java映射的版本也会发生改变。但是以你对目前的映射的理解，你一定会注意到将来的版本中任何可能的二进制不兼容性。

回页首

整型（Integer）
IDL 符号整型（signed integer）到 Java 类型的映射不存在任何问题。IDL的 short 类型映射到 Java 的 short ，IDL 的 long 映射到 Java 的 int ，IDL 的 long long 映射为 Java 的 long 。这些都是直接映射，不会给你带来什么麻烦的。

问题在于 IDL 的无符号整型（unsigned）。Java 编程语言没有unsigned 类型，并且它所有的整数类型都是有符号的。在多数情况下这不会发生问题，但是当一个 IDL无符号整数取值正好落在最高位所限制的取值范围中时，类型转换就会发生不匹配的错误。如果不检查并改正这种错误，转换为 Java后的结果就会是一个负数，而不是一个接近无符号整数类型取值上限的数值。

例如，假设有一个从 IDL 接口返回的 unsigned short 类型值，这一类型的取值范围是0到65535。 Java 的有符号 short 类型能够接收的取值范围是-32768到32767。那么你可以看到，对于任何在32767到65535之间的值映射为 Java 的 short 以后将成为负数。这就造成了不匹配的障碍，必须进行测试。 对于 unsigned short , unsigned long , 以及 unsigned long long 来说也是这样。

这意味着什么呢？首先，我建议以后写 IDL定义时不要再使用无符号整型。这会使事情简单的多。其次，如果你在使用或者支持现有的 IDL 接口，那你 必须测试输入的无符号整数，并确保它在 Java程序中被作为负数正确的处理，或者被拷贝到取值范围较大的变量类型中。

布尔型（Boolean）和8位字节型（octet）
这两种 IDL 类型到 Java 类型的映射也是直接映射。IDL 的布尔常量 TRUE 和 FALSE 映射到相应的布尔量 true 和 false 。

IDL 的字节型 octet 长度为8位，它映射为 Java 的 byte 类型。

字符型（Character）和字符串类型（string）
字符类型的映射有一些困难。首先是所使用的字符集，其次是表示整个字符集所需要的编码位数。不同的语言有不同的字符，它们分别被国际标准化组织映射为不同的字符集。这些字符集代表了某种语言的字母或符号到数字的映射。一种语言中符号的数量决定了这种语言所需要的位宽。现在有8位和16位两种字符集。

IDL 的字符型数据用8位来表示字符集中的一个元素，而 Java的字符型数据用16位无符号整数来表示 Unicode字符。要正确的进行类型转换，Java CORBA 运行时环境验证了所有由 IDL的 char 型映射来的 Java char 型的有效性范围。这一方向的映射没有什么困难，因为我们是把8位的数值映射为16位的数值，Java程序碰到的任何问题都很容易处理，因为空间是足够的。 然而，要把 Java的 char 型映射为 IDL 的 char 型，Java 的 char 型就有可能会超出 IDL使用的字符集所定义的范围。这种情况下就会产生 CORBA::DATA_CONVERSION 的异常。 IDL 的 wchar 仅仅是映射为16位字符集的 IDL 类型，它映射为 Java的基本类型 char 。 如果 wchar 超出了字符集所定义的范围，将会产生 CORBA::DATA_CONVERSION 的异常。

IDL 的 string 类型映射为 java.lang.String 。别忘了 IDL 的 string 是一个 char 的序列。这意味着 IDL 的 string 必须满足 IDL char 和 IDL sequence 的要求。因此，在编译过程中要进行字符串中的字符范围检查和字符序列的越界检查。字符范围非法会引起 CORBA::DATA_CONVERSION 的异常。越界会引起 CORBA::BAD_PARAM 的异常。对于 IDL 的 wstring 类型来说其注意事项和使用规则也是一样的。

浮点型（Floating-point）
因为OMG IDL 和 Java 的浮点型数据都遵从 IEEE 754-1985 Standardfor Binary Floating Point Arithmetic，所以浮点型数据的转换没有问题。然而，目前 Java 编程语言中还没有对IDL 的 long double 类型的支持。 现在还不清楚 java.math.* 是否会增加这一类型作为基本数据类型或新的包，或者说什么时候会增加，也许会作为 java.math.BigFloat 吧。这一问题就留待以后修订了。

映射的合法性检查
我们可以用 Orbacus ORB 带有的 IDL 到 Java 编译器来运行我们的 motheridl.idl 文件：

jidl --output-dir . . \. . \. . MotherIDL.idl
                

这一生成的文件检查映射的合法性。所有的 Java类型都像我们所预期的那样。 唯一的诀窍大概就在于 inout 和 out 参数位置上的数据类型--它们都是 holder。

回页首