Proposal: IDL 4
Justin Wilson edited this page Nov 17, 2023
·
1 revision
In general, the IDL4 mapping is similar to the previous mappings (C++11 and IDL to Java 1.3), with significant differences shown in tables below. Code generation on the backend, however, will be somewhat different and even more so for the Java mapping. Aside from replacing the TAO IDL backend with one that does not reference TAO, the OpenDDS IDL compiler has the basic infrastructure required to achieve the mapping.
The backend of the OpenDDS IDL compiler will need to generate client side C++ files to contain the additional code for the following IDL constructs.
- module - already implemented
- exception - not needed
- interface (only local interfaces)
- typedef - already implemented, but may need to support typedefs of new types
- struct - already implemented, but changed in IDL4-to-C++ (see below)
- struct inheritance
- const - already implemented, minor change in IDL4-to-C++ (see below)
- union - already implemented
- enum - already implemented
- sequence - already implemented, but need to support sequences of newly-supported types (interface)
- sequences of interfaces are used in the core spec (DataReaderSeq and ConditionSeq) and XTypes dynamic lang binding
- array - already implemented
- valuetype (simple usage, no inheritance/abstract/valuebox/factory/truncatable/etc)
The term “Building Block” is used within the spec to describe the specific category of the translation from IDL to the target language. According to section A.2 Annex B of the IDL4 to C++ Language Mapping, the DDS specific mappings include the following Building Blocks.
- Need to have
- Core DataTypes
- modules, constants, integer types, floating point, char, wchar, string, wstring, boolean, octet, sequence, array, struct, and union.
- Interfaces – Basic
- Value Types (partial)
- Extended Data Types
- Features of this building block:
- Structures with Single Inheritance
- Extended Union Discriminators (wchar, octet)
- Maps
- Bitsets
- Bitmasks
- 8-bit Integer Types (already supported)
- Explicitly-Named Integer Types (already supported)
- These should all eventually be supported, but for the most part they’re not required to compile the spec’s IDL except…
- octet-discriminated unions in core XTypes
- struct inheritance could simplify the security spec IDL
- maps in XTypes Dynamic Language Binding
- Features of this building block:
- Anonymous Types (some support already exists)
- Annotations
- Core DataTypes
- Probably don't need
- Interfaces – Full
- Any
- CORBA-Specific – Interfaces
- CORBA-Specific – Value Types
- Components – Basic
- Components – Homes
- CCM-Specific
- Components – Ports and Connectors
- Template Modules
The IDL4 to C++ Language Mapping is similar to the C++11 Language Mapping. There are a few differences noted below.
| Language Construct | IDL-to-C++11 | IDL4-to-C++ |
|---|---|---|
| C++ keywords | Prefixed with cxx | It is stated in 7.1.2 that they are prefixed with _, but in A.1.10.1 it says cxx is the prefix. Additional keywords: atomic_cancel, atomic_commit, atomic_noexcept, char8_t, co_await, co_return, co_yield, concept, consteval, constinit, nullptr, reflexpr, requires, static_assert, synchronized. [xorg is listed as a keyword, but I believe this is a typo] |
| Explicitly-Named Integer Types | None | int8, uint8, int16, uint16, int32, uint32, int64, uint64 |
| Interface | Operations map to virtual functions. | Operations map to pure virtual functions. |
| const | Maps to constexpr for numeric constants and const for strings. | Maps to constexpr for all const types. |
| traits | Defined as IDL::traits. | templates defined in the omg::types namespace, also referenced as CORBA::traits, and, with regards to map traits, they are referred to as IDL::traits |
| “bound” traits | defined to be std::integral_constants with a type of uint32_t | defined to be std::integral_constants with a type of size_t |
| struct | Mapped to C++ classes with accessors for fields. | Mapped to structs with direct access to members. |
| union | wchar and octet are valid discriminator types. | |
| map | “bound” trait only for bounded maps. | “bound” trait for both bounded and unbounded maps. |
| Additional Annotations | @value, @default, @default_literal, @range, @min, @max, @external, @verbatim, @service, @oneway, @ami, @cpp_mapping | |
| string or wstring | Bounded string must be distinct from unbounded string. | Must define omg::types::string and omg::types::bounded_string, but can both be std::string |
The IDL4 to Java Language Mapping is significantly different from the IDL to Java Language Mapping 1.3. In addition to changing the way constructs are mapped, it provides two naming schemes which change the style of the generated code, additional reserved names (assert, enum, and strictfp), and support for long double (as java.math.BigDecimal).
| Language Construct | Java Mapping 1.3 | IDL4-to-Java |
|---|---|---|
| Interface | Public Signature and Operations Interfaces | Single public interface |
| Constants | Public Interface | Public Final Class |
| Sequence | Java Array | Basic Types: specific type that extends List, Non-Basic Types: List |
| Structure | Implements org.omg.CORBA.portable.Streamable, Has field instances. | implements java.io.Serializable, Has accessors for fields. |
| Union | Discriminator method named discriminator | Discriminator method named get_discriminator or getDiscriminator (depends on naming scheme) |
| Enum | Public class, Static method from_int to create enum from integer. | Public enum, Static method valueOf to create enum from integer. |
| Typedef | Direct type replacement in generated code. Holder classes are generated for sequences and arrays. | Direct type replacement in generated code. |
| Value Types | All value types implement ValueBase | Abstract helper class with the suffix Abstract. Concrete class extends helper class. |
| Any | Contains stream related methods, insertion/extraction for TypeCode, strings, java.io.Serializable | |
| Additional Annotations | @value, @default, @default_literal, @range, @min, @max, @external, @verbatim, @service, @oneway, @ami, @cpp_mapping |
“Implementers of this specification that target a technology different than CORBA may map Int8 and UInt8 to typedefs in a different module. For example, a typedef for int8 for DDS could be mapped to DDS::Int8.”
- Create a new language mapping for IDL4 to C++11 based on the existing C++11 mapping.
- Use new language mapping in one test. This test should be extended as additional capabilities are implemented.
- Update support for structs (direct access to members).
- Update support for const
- Update support for string and wstring
- Implement support for local interfaces.
- Implement support for local interface types when used in
- sequences
- unions
- arrays
- structs
- others?
- Implement partial support for valuetype
- Implement support for built-in annotations required by the IDL that comes from the specs
- @external
- @optional
- Complete the support for anonymous types
- Implement some support for Extended Data Types required by the IDL that comes from the specs
- Demonstrate the language mapping can handle
- Core DDS IDL
- XTypes/DynamicData IDL
- RTPS (w/ DDS Security)
- Convert OpenDDS core library to language mapping
- Convert tests to language mapping
- Remove obsolete C++ language mappings
- Incorporate idl2jni into opendds_idl.
- Update support for interface
- Add a test and keep extending the tests as capabilities are added.
- Update support for constants
- Update support for sequences
- Update support for structs
- Update support for union
- Update support for enum
- Update support for typedef
- Implement support for valuetypes
- Gap analysis to determine if there are any remaining gaps between C++ and Java support
- Remove idl2jni
These may require changes in the IDL frontend.
In general, each of these features should be a vertical slice, i.e., it should be supported in
- The IDL frontend
- The IDL backends
- C++
- Java
- DCPS Layer
- Transport Layer (RTPS et al)
- Tests
- Support escaping C++ keywords
- Implement support for traits and bound traits
- Support the following annotations (some are already supported, some don’t have any impact on the language mapping)
- @optional (xtypes, struct)
- @must_understand (xtypes, struct)
- @non_serialized (xtypes, struct)
- @id(xtypes, struct and union except discriminator)
- @hashid(xtypes, struct and union except discriminator)
- @external (xtypes, struct and union except discriminator)
- @try_construct (xtypes, struct and union except discriminator)
- @key (xtypes, struct and union discriminator)
- @bit_bound (xtypes, enum and bitmask)
- @extensibility (xtypes, type declarations)
- @mutable (xtypes, type declarations)
- @appendable(xtypes, type declarations)
- @final(xtypes, type declarations)
- @nested(xtypes, type declarations)
- @default_nested (xtypes, type declarations)
- @default_literal(xtypes, enum)
- @value(xtypes, enum)
- @position(xtypes, bitmask)
- @autoid (xtypes, module, struct, and union)
- @verbatim(xtypes)
- @default (not in xtypes spec)
- @range (xtypes)
- @min (xtypes)
- @max (xtypes)
- @service (not in xtypes spec, declares service, e.g., DDS)
- @cpp_mapping (not in xtypes spec, customized mapping)
- Support extended data types
- Structures with Single Inheritance
- Union Discriminators (wchar, octet)
- Maps
- Bitsets
- Bitmask