IDL4 to Java Language Mapping Avatar
  1. OMG Specification

IDL4 to Java Language Mapping — All Issues

  • Acronym: IDL4-Java
  • Issues Count: 7
  • Description: All Issues
Closed All
All Issues

Issues Descriptions

Package prefix specified at the IDL to Java translator

  • Key: IDL4JAV-1
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    Predecessor: https://issues.omg.org/browse/I2JAV13-11

    Many of the IDL to Java translators support an option to specify a Java package prefix for the generated code (e.g. Oracle idlj option -pkgPrefix; JacORB option -i2jpackage; rtiddsgen option -package).
    This is not exactly equivalent to hard coding the prefix as modules in the IDL: When using the translator option, other language mappings do not see the prefix.

    The package prefix provided to the IDL translator may produce a conflict with names in the IDL file.
    Example:

    // file: test.idl
    module test {
    
       enum com_t { zero, one };
    
       struct org_t {
          short foo;
       };
    
       typedef string<16> net_t;
    
       struct structure {
          com_t com;   // "com" is in conflict when providing prefix option such as: com.acme
          org_t org;   // "org" is in conflict when providing prefix option such as: org.acme
          net_t net;   // "net" is in conflict when providing prefix option such as: net.acme
       };
    
    };
    

    Notice that the Java generated for this IDL does not compile but it does compile for other languages (C++, Ada, etc).

    Section 7.1.1.1 (Name Transformation Rules) contains:

    If the mapped name or identifier collides with a reserved name in 7.1.2, the collision is resolved by prepending an underscore ("_") to the mapped name.

    I suggest adding a further sentence:

    This also applies to name collisions caused by a Java package prefix specified at the IDL to Java translator.
    
  • Reported: IDL4-Java 1.0a1 — Tue, 13 Aug 2019 15:34 GMT
  • Disposition: Resolved — IDL4-Java 1.0
  • Disposition Summary:

    Document conflict resolution rules for compiler and vendor-extension settings

    Many IDL to Java translators provide extensions to introduce package prefixes for the generated code. Even though these rules are out of the scope of this specification, in this resolution we add a note indicating that name resolution rules may be also applied to collisions caused by these settings.

  • Updated: Fri, 18 Sep 2020 17:05 GMT

Constants mapping is incomplete/broken

  • Key: IDL4JAV-5
  • Status: closed   Implementation work Blocked
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    The constant mapping is prone to namespace collision

  • Reported: IDL4-Java 1.0a1 — Thu, 26 Sep 2019 14:06 GMT
  • Disposition: Resolved — IDL4-Java 1.0
  • Disposition Summary:

    Restructure Constants Mapping to Address all Possible Use Cases

    With this resolution, we introduce a new default mapping for constants that addresses all possible scenarios. The previous mapping, which provided a simpler but partial solution, is now an optional mapping that can be exercised with the @java_mapping annotation.

    NOTE—The example code in the revised text takes into account the names and conventions introduced in the resolution of IDL4JAV-4. For simplicity, the resolution of IDL4JAV-4, which edits all code snippets in the document, applies the new default mapping of constants throughout the document.

  • Updated: Fri, 18 Sep 2020 17:05 GMT

Provide additional flexibility in language mapping

  • Key: IDL4JAV-3
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    This issue is a placeholder for any feature request in terms of namespace prefix flexibility, compatibility with CORBA IDL, or possible additions to the java mapping annotation to adjust the language mapping.

    This issue should be closed with no change if no such features or concerned are filed.

  • Reported: IDL4-Java 1.0a1 — Tue, 24 Sep 2019 19:16 GMT
  • Disposition: Closed; No Change — IDL4-Java 1.0
  • Disposition Summary:

    No extra functionality was formally requested as part of FTF

    This placeholder issue was not used to suggest any extra functionality or flexibility in the language mappings. Therefore, we close it with no changes.

    In the future, issues like this should only be created if there's an actual request or concern.

  • Updated: Fri, 18 Sep 2020 17:05 GMT

Naming Conventions and Transformation Rules

  • Key: IDL4JAV-4
  • Status: closed   Implementation work Blocked
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    Section 7.1.1.1 provides ambiguous guidance on name mapping from IDL to Java 8.

    We should adopt the solution agreed upon for the IDL to C# Language Mapping.

    On a side note, many Java snippets use semicolons at the end of a class declaration, which is unnecessary in Java.

  • Reported: IDL4-Java 1.0a1 — Thu, 26 Sep 2019 14:02 GMT
  • Disposition: Resolved — IDL4-Java 1.0
  • Disposition Summary:

    Introduce IDL Naming Scheme and Java Naming Schemes

    To address this issue, we are adopting the approach we followed in the IDL to C# Language Mapping specification. In a nutshell, we introduce two naming schemes that can be applied when IDL transforming type identifiers and names to Java.

  • Updated: Fri, 18 Sep 2020 17:05 GMT

Address the CORBA specific mapping[s]

  • Key: IDL4JAV-2
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    For example, these building blocks, etc:

    • CORBA specific interfaces
    • "Any" type
    • CORBA specific value-type
    • System Exception
    • Pseudo Objects [may remove]
    • org.omg package
  • Reported: IDL4-Java 1.0a1 — Tue, 24 Sep 2019 18:28 GMT
  • Disposition: Resolved — IDL4-Java 1.0
  • Disposition Summary:

    Define CORBA-Specific Mappings to CORBA in Annex A

    This issue adds all the required CORBA-specific mappings to Annex A.1: CORBA-Specific Mappings. It includes a CORBA-specific mapping for Exceptions, TypeCode, Object, Any, Interfaces, and Value Types. The rest of mappings are derived from applying the generic IDL to Java mapping rules specified throughout the document.

    The resolution of this issue takes into account the changes introduced with IDL4JAV-4 to provide an IDL Naming Scheme and a Java Naming Scheme.

  • Updated: Fri, 18 Sep 2020 17:05 GMT

Typos and Inconsistencies

  • Key: IDL4JAV-13
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    The revised submission contains a number of typos and inconsistencies that should be fixed:

    • In Clause 7.2.4.2.1.1, Sequence of Basic Types, IntarfaceName should be InterfaceName.
    • In Clause 7.2.4.2.1.2, Sequence of non Basic Types, the text describing when to throw an exception is somewhat repetitive.
    • In Clause 7.2.4.3.2 Unions, the requirement for implementing java.io.Serializable is repeated.
  • Reported: IDL4-Java 1.0a1 — Sat, 21 Mar 2020 13:43 GMT
  • Disposition: Deferred — IDL4-Java 1.0
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 14 Jul 2020 20:04 GMT

Typo fixes

  • Key: IDL4JAV-7
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    In section 7.2.4.2.1.1 on page 13 top of page after end of fixed font Java code:

    Where:
    • <IntarfaceName> is the interface name indicated in Table 7.4.

    <IntarfaceName> should be <InterfaceName>

    In Clause 7.2.4.2.1.2, Sequence of non Basic Types, the text describing when to throw an exception is somewhat repetitive.

    In Clause 7.2.4.3.2 Unions, the requirement for implementing java.io.Serializable is repeated.

    In section 7.2.4.3.2 on page 16 paragraph before the union U1 example:

    [...] The first modifier method shall
    take no arguments, return void, and setsthe discriminant to the first available default value starting from a 0 index of the
    discriminant type.

    setsthe should be set the.

    In section 8.1.3 table 8.2 column "IDL Construct", repeated typo:
    Accesor should be Accessor.
    In particular, on page 32:

    Structure Member Name in
    Accesor/Modifier Methods

    Union Member Name in
    Accesor/Modifier Methods

    and on page 33:

    Interface Attribute Name in
    Accesor/Modifier Methods

    Exception Member Name in
    Accesor/Modifier Methods

    Bitfield Name in Bitset
    Accesor/Modifier Methods

    Throughout the document URIs starting with "http://" should start with "https://" instead.

  • Reported: IDL4-Java 1.0a1 — Mon, 30 Dec 2019 12:49 GMT
  • Disposition: Deferred — IDL4-Java 1.0
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 14 Jul 2020 20:04 GMT