1. OMG Mailing List
  2. No Description

Open Issues

  • Issues not resolved
  • Name: idl4-java-rtf
  • Issues Count: 19

Issues Descriptions

Definition of CORBA specific Any (A.1.4 Any) needs to align with 7.3 Any

  • Status: open  
  • Source: Micro Focus ( Simon McQueen)
  • Summary:

    7.3 Any says:

    "The IDL any type shall be mapped to org.omg.type.Any type."

    A.1.4 Any says:

    "The IDL type any maps to a public class named org.omg.CORBA.Any with the following definition

    package org.omg.CORBA;
    public class Any {
    ..."

    Suggested solution:

    Replace class declaration with:

    "package org.omg.CORBA;
    public class Any implements org.omg.type.Any {
    ..."

  • Reported: IDL4-Java 1.0b2 — Thu, 14 Oct 2021 11:04 GMT
  • Updated: Thu, 14 Oct 2021 12:27 GMT

@java_mapping promote_integer_width does not mention octet

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    IDL 4.2 section 7.4.1.4.3 Constants consistency rules on page 32 contains

    • An octet constant can be defined using an integer literal or an integer constant expression but values outside the range 0…255 shall be treated as an error.

    ptc/20-05-17 section 7.2.4.1.6 maps IDL octet to Java byte.
    For mapping IDL const octet values 128 to 255 to Java, it should be permissible to apply promote_integer_width to octet.

  • Reported: IDL4-Java 1.0 — Fri, 10 Jul 2020 08:28 GMT
  • Updated: Tue, 28 Sep 2021 17:42 GMT

Missing extended basic types section

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    This building block section is missing (e.g. sbyte).

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:24 GMT
  • Updated: Wed, 11 Aug 2021 17:24 GMT

Mapping to alternative identifier formats

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    It seems every section has this deviation of alternative identifier mappings. I find that it maps the document more difficult to read. The document at large should provide canonical text and examples. These alternatives should be placed in a section that caters to those alternatives with easy links to this section elsewhere in the document.

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:23 GMT
  • Updated: Wed, 11 Aug 2021 17:23 GMT

Application of Non-Standard Annotations

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    I could not find a place that discussed what is expected if an IDL compiler encounters an annotation that it can parse but does not understand.

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:17 GMT
  • Updated: Wed, 11 Aug 2021 17:17 GMT

Annotation usage

  • Status: open   Implementation work Blocked
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    The section on annotations should contain examples of how to use the various standard annotations.

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:14 GMT
  • Updated: Wed, 11 Aug 2021 17:14 GMT

Anonymous types sections needs text

  • Status: open   Implementation work Blocked
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    This section needs to be filled out with examples of anonymous IDL types.

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:12 GMT
  • Updated: Wed, 11 Aug 2021 17:12 GMT

Annotations should not be used for examples in a canonical mapping

  • Status: open   Implementation work Blocked
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    The example uses annotation to define the type. The mapping should be clean/pure without annotations. The annotation should be moved to the sections on annotations.
    // IDL
    enum AnEnum

    { X, Y }

    ;

    // Java
    public enum AnEnum {
    X,
    Y;
    private int value;
    private AnEnum(int value)

    { this.value = value; }

    public int getValue()

    { return value; }

    public static AnEnum valueOf(int v)

    { // return X, Y, or raise java.lang.RuntimeException }

    7.17 Standardized Annotations
    }

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:09 GMT
  • Updated: Wed, 11 Aug 2021 17:09 GMT

Union exmple uses octet which is not allowed as a discrimant

  • Status: open   Implementation work Blocked
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    Same as the description

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:07 GMT
  • Updated: Wed, 11 Aug 2021 17:07 GMT

Table 7.2

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    Ensure the correct separation of building block basic types (e.g. sbye)

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:04 GMT
  • Updated: Wed, 11 Aug 2021 17:04 GMT

Document Review: Table 7.1

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    There needs to be a section on IDL interfaces being mapped to Java 8 interfaces which provide the capability to be a proper container. This removes the need for the old fooPackage id foo were defined in an IDL interface named foo.

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:02 GMT
  • Updated: Wed, 11 Aug 2021 17:02 GMT

Bitset inheritance

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    How are bitsets that use inheritance mapped?

  • Reported: IDL4-Java 1.0b2 — Tue, 20 Oct 2020 18:02 GMT
  • Updated: Tue, 20 Oct 2020 18:05 GMT

Provide strong abstraction for arrays

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    The ptc/19-07-02 section 7.2.4.4 proposes a weak mapping for IDL arrays in that they are mapped directly to Java arrays.
    This means that the fixed size nature of IDL arrays cannot be enforced at the location of usage (e.g. index checking and handling of variable size operations of java.util.List).

    On the other hand, 7.2.4.2.1.1 does define an abstraction for "Sequence of Basic Types", see Table 7.4 where e.g. sequence<boolean> is mapped to the interface BooleanSeq.
    A similar mapping could be defined for IDL arrays.

    Example:

      // IDL
      enum Color { RED, GREEN, BLUE };
    
      typedef Color ColorArray[3];
    

    could be mapped to

      public enum Color {
        // [...]
      }
    
      public class ColorArray implements org.omg.type.Array<Color> {
        public ColorArray() {
          elementData = new Color[3];   // initialize private member
        }
        // [...] most of the operations can be implemented in the superclass
      }
    

    The generic abstract class org.omg.type.Array would provide getter, setter, and other methods. It could also throw an exception on use of java.util.List operations that undermine the fixed size. I can provide a demo implementation of the class if desired.

    If it is desired to maintain the possibility of using plain Java arrays then the mapping could be made switchable via an annotation.

  • Reported: IDL4-Java 1.0a1 — Mon, 23 Mar 2020 05:24 GMT
  • Updated: Tue, 14 Jul 2020 20:04 GMT
  • Attachments:

Anonymous types are a separate Building Block

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    Examples given throughout ptc/19-07-02 make indiscriminate use of anonymous types; see

    • 7.2.4.2.1.2 struct MyType
    • 7.2.4.4 struct S2
    • 7.2.4.6 struct MyType
    • 7.14.3.1 struct S4

    For IDL compatibility with other mappings that do not support anonymous types (see e.g. C++11 mapping version 1.4 stion 6.2), the examples should preferably use typedefs.
    Further, it should be mentioned that anonymous types can incur portability problems when used with other language mappings.

  • Reported: IDL4-Java 1.0a1 — Mon, 23 Mar 2020 05:01 GMT
  • Updated: Tue, 14 Jul 2020 20:04 GMT

Sequences are not concretized

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    ptc/19-07-02 section 7.2.4.2.1 defines the mapping of sequences of basic and non basic types in terms of Java interfaces.
    However, the classes implementing the interfaces are not defined.
    The implementation classes are required for actual programming.
    If it is intended that the user shall provide own implementations then this should be expressly stated.

  • Reported: IDL4-Java 1.0a1 — Mon, 23 Mar 2020 04:47 GMT
  • Updated: Tue, 14 Jul 2020 20:04 GMT

Union mapping

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    Something I noticed while looking at the union mapping for CORBA. Why is it that the IDL4 mapping uses two underscores prepended to the default method (e.g. __default v.s. _default)?

    If there is no technical reason for it I think the single underscore is preferred.

  • Reported: IDL4-Java 1.0a1 — Wed, 6 May 2020 21:07 GMT
  • Updated: Tue, 14 Jul 2020 20:04 GMT

Interfaces - Full should define a FooOperations interface

  • Status: open  
  • Source: Real-Time Innovations ( Fernando Garcia-Aranda)
  • Summary:

    Interfaces - Full should define a FooOperations interface like we have done in the IDL to C# Language Mapping.

    Also, public abstract void op1(S sIn); should be changed to void op1(S sIn);.

  • Reported: IDL4-Java 1.0a1 — Tue, 10 Dec 2019 21:57 GMT
  • Updated: Tue, 14 Jul 2020 20:04 GMT

Typo fixes

  • Status: open  
  • Source: Airbus Group ( Oliver 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
  • Updated: Tue, 14 Jul 2020 20:04 GMT

Typos and Inconsistencies

  • Status: open  
  • Source: Real-Time Innovations ( 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
  • Updated: Tue, 14 Jul 2020 20:04 GMT