The jbi4corba component support the following data types defined in the CORBA specification.
| IDL Types | Java Types | WSDL Types | Comment |
| boolean | boolean | xsd:boolean | |
| char | char | xsd:unsignedShort | |
| wchar | char | xsd:unsignedShort | |
| string | String | xsd:string | |
| wstring | String | xsd:string | |
| short | short | xsd:short | Range not set in corresponding xsd field |
| unsigned short | short | xsd:short | Range not set in corresponding xsd field |
| long | int | xsd:int | Range not set in corresponding xsd field |
| unsigned long | int | xsd:int | Range not set in corresponding xsd field |
| long long | long | xsd:long | Range not set in corresponding xsd field |
| unsigned long long | long | xsd:long | Range not set in corresponding xsd field |
| float | float | xsd:float | |
| double | double | xsd:double | |
| octet | byte | xsd:byte | |
| any | Object | xsd:anyType |
| IDL Types | Java Types | WSDL Types |
| long double | not available at this time in IDL to java mapping |
Supported Constructed Data Types
| Type | Java Types | WSDL Types |
| Struct | The IDL struct is mapped in a java class that implements org.omg.CORBA.portable.IDLEntity. In this class there are a public attribute for each attribute of the struct. |
The IDL struct is mapped in a xsd:complexType with the name of struct. This complexType contains a sequence of elements (one element for each attribute of struct) |
| Sequence | There are two type of sequence: 1) a sequence of a primitive data type. 2) a sequence of a non primitive data type. A sequence of a primitive is mapped in a java class that implements org.omg.CORBA.portable.StreamableValue and contains a public attribute array of a type defined in the IDL file. A sequence of a non primitive data type is not mapped in any java class. Both the sequence's type generate the helper and the holder class. |
The IDL sequence is mapped in a xsd:complexType that contains a xsd:sequence of one element where minOccurs=0; nillable=true and name is the same of the element defined in the IDL file. |
| Enum | The CORBA and the JAVA implementation of th enumeration are different. The component provides a standard implementation with all the methods used inside the associated corba helper class |
<xsd:simpleType name="myEnum"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="A"/> <xsd:enumeration value="B"/> <xsd:enumeration value="C"/> </xsd:restriction> </xsd:simpleType> |
| Array | Supported with limitations | |
| Union | The Union type is converted in an annotated Object, or a Wrapper class of the object (used when direct jaxb the annotation is not possible, for example in parameters or Union of Unions Please se the union issue. |
<xs:complexType name="myUnion"> <xs:sequence> <xs:choice minOccurs="0"> <xs:element name="A" type="xs:int"/> <xs:element name="B" type="xs:float"/> <xs:element name="C" type="xs:int"/> </xs:choice> </xs:sequence> </xs:complexType> |
| string | java.lang.String | xsd:string |
| wstring | java.lang.String | xsd:string |
| exception | like structs | like structs |
Unsupported Constructed Data Types
| Type | Java Types | WSDL Types | comment |
| fixed | java.math.BigDecimal | xsd:decimal | Not supported by idlj, for more information see the idlj documentation (section restrictions) |
| typedef | the redefined type | the redefined type | support is partial please see the note |
Note on typedef
Typedef types aren?t explicitly supported. Currently typedef conversion to WSDL type isn?t supported. When the type of a typedef defined type is statically known the component provide a rudimentary support using the base type of the typedef type. So for example if we have Typedef A B; And then we use B as a method parameter or a struct element then A would be used instead. From the information content point of view this is acceptable since A and B have the same information. The same applies when the typedef is used to declare a sequence. When the type of a corba object must be recognized at runtime the typedef support is not sufficient. This happens in particular when a typedef defined type is used inside a any type.
The IDL value types are partially supported, in fact the component is able to manage all the value types that can be represented as a JavaBean. Where possible value type are treated like structs, this means that only state members are considered by the component, while initializers and methods are ignored. Only regular value type have this limited support.
| Type | Supported |
| Regular | Yes |
| Boxed | No |
| Abstract | No |
Support is available for standard interfaces, local and abstract interfaces aren't supported.
A CORBA interface may contain different types of declarations inside. The following table summarize it specifying the support level of the component.
| Element Declaration | Support |
| Const | No |
| Type | Yes |
| Exception | Yes |
| Attribute | No |
| Operation | Yes |
IDL has other constructs and keyword. Here is summarized the support level for each of them
| IDL construct | Support |
| native | No |
| const | No |
| event | No |
| component | No |
| home | No |
There is a idlj issue about union with boolean (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4504275). If we have this IDL:
union DNTypeOpt switch (boolean)
{
case TRUE: DN value;
};
Idlj converts it in a class containing:
private void verifyDefault( boolean value )
{
switch (value) {
case true:
throw new org.omg.CORBA.BAD_OPERATION() ;
default:
return;
}
}
Which clearly doesn't compile (contains a switch using a boolean). To correct that, the IDL must be changed manually in:
union DNTypeOpt switch (boolean)
{
case TRUE: DN value;
case FALSE: <another type not DN> not_used;
};
In this case the method verifyDefault is no more created ant the classes are generated correctly.