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.

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 {
..."

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.

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

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.

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.

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

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

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

;

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

public int getValue()

public static AnEnum valueOf(int v)

7.17 Standardized Annotations
}

Same as the description

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

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.

How are bitsets that use inheritance mapped?

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.

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.

The constant mapping is prone to namespace collision

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.

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.

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.

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.

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.

For example, these building blocks, etc:

• CORBA specific interfaces
• "Any" type
• CORBA specific value-type
• System Exception
• Pseudo Objects [may remove]
• org.omg package

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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);.