IDL4JAV — Package prefix specified at the IDL to Java translator

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.