I2JAV13 — Package prefix specified at the IDL to Java translator

This is intended for the Joint Initial submission to the IDL4 to Java Language Mapping RFP,
mars/18-08-01.
However, on filling in the OMG issue reporting form, I could not find a way to specify this; as a fallback, I reference the IDL to Java Mapping 1.3 (formal/08-01-11) to which the same issue also applies.

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 4.2 (Names) contains:

In general IDL names and identifiers are mapped to Java names and identifiers with no change.
If a name collision could be generated in the mapped Java code, the name collision is resolved by
prepending an underscore (_) to the mapped name.

Section 7.1.1 of mars/18-08-01 contains similar text.

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.