IDL to Java Language Mapping Avatar
  1. OMG Specification

IDL to Java Language Mapping — Open Issues

  • Acronym: I2JAV
  • Issues Count: 10
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Package prefix specified at the IDL to Java translator

  • Key: I2JAV13-11
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    This is intended for the Joint Initial submission to the IDL4 to Java Language Mapping RFP,
    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.

    // 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.
  • Reported: I2JAV 1.3 — Wed, 3 Oct 2018 09:07 GMT
  • Updated: Tue, 16 Oct 2018 19:37 GMT

Description of ORB.init parameters insufficient

  • Key: I2JAV13-2
  • Legacy Issue Number: 3643
  • Status: open  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    I have a number of questions/concerns about the description/usage of
    ORB.init arguments/properties.

    1. There are only two properties described in the Java mapping spec:
    org.omg.CORBA.ORBClass and org.omg.CORBA.ORBSingletonClass. Setting these
    via property are described, but not setting these via application string
    array (ie., args in main). Yet the spec says these values can be obtained
    via the args array. I believe most folks assume "-ORBClass xxx" is the
    convention, since that's what the JDK's ORB uses, but it's not documented.

    2. Ditto for applet parameters. It's assumed that they are of the form

    <param name = "org.omg.CORBA.ORBClass" value = "xxx">

    but it is not documented.

    3. Can this convention be generalized to accommodate the argument naming
    convention in the core spec? If we follow the convention that says
    org.omg.CORBA.ORBClass becomes -ORBClass; then can we say that a parameter
    -ORBXXX may also be specified by the property or applet parameter

    4. The text around the ORB arguments is tightly coupled to only ORBClass
    and ORBSingletonClass. It does not seem to expect other args/properties.
    For example: "...when creating an ORB instance, the class names of the ORB
    implementation are located using the following search order: ...". I
    assume the following search order also applies to any args/props.

    5. The spec doesn't allow for extensions.

    "See Table 1-3 for a list of the property names and values that are
    recognized by
    ORB.init. Any property names not in this list shall be ignored by

    Has the INS spec updated this table with -ORBInitRef and
    -ORBDefaultInitRef, for example? And the interceptor spec assumes that
    services are allowed to have their own arguments. And what about
    proprietary extensions? Given the word "shall", any extensions are

    6. Repeated arguments fall apart when presented as Properties. For
    example, the INS spec allows for the following invocation:

    java myapp -ORBInitRef XX=xx -ORBInitRef YY=yy -ORBInitRef ZZ=zz

    Since Properties entries are <key, value> pairs, and only one pair for a
    given key can exist, then if we tried entering the above as Properties we'd
    only get on of them, not all. I'm not sure how to fix this. Dictate that
    XX, YY, ZZ be the end of the ORBInitRef string rather than the start of a
    new string, perhaps? So then, specifying these as system properties for
    example, we'd have:

    java myapp -Dorg.omg.CORBA.ORBInitRefXX xx -Dorg.omg.CORBA.ORBInitRefYY yy
    -Dorg.omg.CORBA.ORBInitRefZZ zz

    That causes ugly parsing problems. We'd have to search the whole list of
    properties that contained a key that merely BEGAN with
    "org.omg.CORBA.ORBInitRef". And this falls apart in applets; we can get a
    list of all Properties, but we cannot get a list of all applet parameters.
    Personally I think this is a failing in the applet class, but that's life
    as we know it.

    I'm sorry to raise this as one issue instead of six, but most of these
    points are tightly coupled, so I didn't want to distance them from each
    other. And I'd like them all to be answered together anyway.

  • Reported: I2JAV 1.0 — Thu, 25 May 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Java source code for org.omg.PortableServer.POAOperations

  • Key: I2JAV13-7
  • Legacy Issue Number: 5646
  • Status: open  
  • Source: SAS Institute Inc. ( Biff Beers)
  • Summary:

    The Java source code for org.omg.PortableServer.POAOperations in ptc/02-06-14 defines the method create_reference_with_id as throwing org.omg.PortableServer.POAPackage.WrongPolicy. However, the CORBA/IIOP 2.4 specification (formal/00-10-01) specifies this operation as NOT raising any exceptions (see section Which is correct?

  • Reported: I2JAV 1.1 — Thu, 19 Sep 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Specification does not provide mapping spec for Home, Component and Event

  • Key: I2JAV13-6
  • Legacy Issue Number: 15709
  • Status: open  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The specification does not provide mapping descriptions for Home and Event IDL definitions (already part of CORBA 3.0) or Component (new in CORBA 3.1).

  • Reported: I2JAV 1.3 — Fri, 8 Oct 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

section 1.21.3 IDLEntity

  • Key: I2JAV13-8
  • Legacy Issue Number: 9795
  • Status: open  
  • Source: at&t ( Dave Brink)
  • Summary: section 1.21.3 IDLEntity inclides the Serializable interface, but if an IDLEntity has a union, it will result in Holder classes (i.e. FloatHolder) which do not implement the Serializable interface. This results in NotSerializable exceptions being created when trying to use such objects with java serialization. The quick fix would be to specify that "public interface Streamable" should extend, since the holder classes extend from that as well.

  • Reported: I2JAV 1.1 — Fri, 26 May 2006 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

definition of FixedHolder should have been removed

  • Key: I2JAV13-4
  • Legacy Issue Number: 5893
  • Status: open  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    The resolution of issue #3668 should have removed the definition of FixedHolder. There is no need for a Holder for an anonymous Fixed type since none can be defined. Type specific Holders are necessary in order to define the correct read and write operations that use the write_fixed and read_fixed defined by the resolution of 3668.

    Proposed resolution:
    Remove the definition of FixedHolder from section (page 1-11).

  • Reported: I2JAV 1.1 — Tue, 1 Apr 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Messaging sendc and sendp missing from portability interfaces

  • Key: I2JAV13-3
  • Legacy Issue Number: 3068
  • Status: open  
  • Source: Ericsson ( Chris Smith)
  • Summary:

    The Messaging Specification was adopted before Java Portability
    layer was really in place. In order to make portability work
    with the asynchronous stubs which will in future be generated,
    some things may be added to the portability interface.

    Each stub has a sendc_<op> and sendp_<op> operation which
    will need to call on the portable stub layer.

    A first glance at the requirements to make a portable
    implementation suggest that a sendc_invoke and sendp_invoke
    operation will probably need to be added to ObjectImpl and

    I dont know if this is viewed as a "compatible" class change
    for JDK, or whether we will need to put derived classes
    in CORBA_3_0 package....

  • Reported: I2JAV 1.0 — Tue, 23 Nov 1999 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

J2EE ORB Socket Factory API

  • Key: I2JAV13-9
  • Legacy Issue Number: 5108
  • Status: open  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    In order to meet the interoperability compliance requirements,
    ORBs must include an IIOP implementation using TCP/IP plain text
    sockets. J2EE implementations are required to support CSIv2 and
    thus need additional control over the sockets an ORB creates.
    It may be necessary

    • to get the ORB to listen on additional sockets, of differing
    • to get the ORB to connect to alternative sockets, of different
      types, for a given IOR
    • for information about these sockets to be included in object
      references exported by the ORB
    • for socket data to be available to request interceptors, e.g
      SSL certificates

    Portable IORInterceptors can be used to add this information as
    tagged components in the profiles within an IOR.

    A mechanism is required to modify the ORB's behaviour to allow
    it to handle different socket types, listen on additional sockets,
    connect to alternative sockets and make additional data available
    to interceptors.

    Since this is a J2EE requirement which needs speedy resolution,
    it seems appropriate to resolve it by the addition of Java
    specific APIs in the IDL to Java specification. For example,

    • a pluggable ORB socket factory could be introduced which would
      be used whenever the ORB needed to create a serverSocket or an
      outbound socket for a given IOR or end point
    • a means of registering such a socket factory would be required.
      Options for this include:-
      . adding an ORB method: this may cause problems in initialisation
      . adding a Java specific extension to the PI ORBInitInfo interface
      so that the registration would need to be called from the
      pre_init/post_init methods in an ORBInitializer: this ties the
      Socket Factory with PIs, but both are likely to be required
      for J2EE.
    • a means of specifying ports on which an ORB/POA should listen
      would be useful but this may be infeasible as part of this issue
      due to the variety of ORB/POA implementations.
    • the PI Client and ServerRequestInfo and IORInfo interfaces may
      need to be extended to support access to Connection related data
  • Reported: I2JAV 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Java ORB Id

  • Key: I2JAV13-1
  • Legacy Issue Number: 3665
  • Status: open  
  • Source: Oracle ( Harold Carr)
  • Summary:

    There are several reasons that Java ORB.init should support
    ORBId (without compromising security). For example:

    • Services built on Portable Interceptors work in relation to the ORB
      with which they are registered. There needs to be some means of
      identifying this ORB (besides its reference) so other services or
      facades (e.g., JNDI) can use the same ORB.
    • A Server Activation Framework needs an ORB Id to identify a particular
      orb (which hosts a persistent POA) within a server. The triple:
      server id, orb id, poa name is conceptually embedded in the adapter
      id of a POA making it unique.
  • Reported: I2JAV 1.0 — Tue, 30 May 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

wrong enumeration value for SetOverrideType

  • Key: I2JAV13-5
  • Legacy Issue Number: 7846
  • Status: open  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    In ptc/02-01-01, the latest compendium of predefined code for the IDL to Java mapping, the enumerations values captured in org.omg.CORBA.SetOverrideType are SET_OVERRIDE and ADD. The correct values are SET_OVERRIDE and ADD_OVERRIDE.

  • Reported: I2JAV 1.1 — Thu, 7 Oct 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT