Java to IDL Language Mapping Avatar
  1. OMG Specification

Java to IDL Language Mapping — Closed Issues

  • Acronym: JAV2I
  • Issues Count: 13
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

Urgent issue: javax.rmi.CORBA.Stub serialVersionUID

  • Key: JAV2I13-17
  • Legacy Issue Number: 5332
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    I'd like to raise the following as an urgent issue for the Java to IDL
    RTF:

    The javax.rmi.CORBA.Stub class defined in the Java to IDL
    specification does not explicitly define its serialVersionUID, yet
    this value is crucial for interoperability. The sender's Stub
    repository ID must be compatible with that of the receiver.

    Without a standard value, even compiler differences can affect the
    serialVersionUID.

    In our case, we removed an unnecessary protected constructor before
    our J2SE 1.4.0 implementation shipped. Unfortunately, this broke
    interoperability with our (and others') previous implementations, and
    it is seriously affecting one of our customers.

    We would like to standardize the following (older) value so we can
    then patch our 1.4.0 implementation:

    Proposed resolution:

    Add the following serialVersionUID to the Stub class in Java to IDL
    (ptc-02-01-12) 1.5.1.2:

    // Java
    public abstract class Stub
    extends org.omg.CORBA_2_3.portable.ObjectImpl
    implements java.io.Serializable

    { private static final long serialVersionUID = 1087775603798577179L; ... }
  • Reported: JAV2I 1.2 — Mon, 3 Jun 2002 04:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    Closed, accepted. See proposed revised text below

  • Updated: Fri, 6 Mar 2015 21:39 GMT

Stream encoding for omitted optional custom data

  • Key: JAV2I13-16
  • Legacy Issue Number: 5330
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The resolution for issue 3151 does not make it clear how to encode a custom
    valuetype that has no optional custom data. This includes custom types
    whose writeObject() method calls defaultWriteObject() but writes no additional
    data, and custom types that don't write any data at all.

    Tihs case could be handled by always writing the org.omg.customRMI.* wrapper
    even if there is no data inside of it. However, this is very wasteful of
    space. A better approach would be to write a null valuetype (0x00000000) to
    indicate the omission of the optional data. The optional data cannot be omitted
    entirely, since the receiver would not be able to correctly parse the stream.

    Proposed resolution:

    Change paragraph "d" in section 1.4.10 from the following:

    d. (optional) Additional data written by writeObject, encoded as specified below.
    For format version 1, the data is written "as is". For format version 2, the
    data is enclosed within a CDR custom valuetype with no codebase and repid
    "RMI:org.omg.custom.<class>" where <class> is the fully-qualified name of the
    class whose writeObject method is being invoked.

    to the following:

    d. Additional data written by writeObject, encoded as specified below. For format
    version 1, this data is optional and if present must be written "as is". For
    format version 2, if optional data is present then it must be enclosed within a
    CDR custom valuetype with no codebase and repid "RMI:org.omg.custom.<class>"
    where <class> is the fully-qualified name of the class whose writeObject method
    is being invoked. For format version 2, if optional data is not present then a
    null valuetype (0x00000000) must be written to indicate the absence of optional data.

  • Reported: JAV2I 1.2 — Wed, 29 May 2002 04:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    Closed, accepted. See proposed revised text below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Support for serialPersistentFields

  • Key: JAV2I13-15
  • Legacy Issue Number: 2091
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Moving forward to JDK 1.2, the IDL value type data mapping needs
    to factor in the new serialPersistentFields declaration. And there"s
    an interesting question whether the existence of a writeReplace method
    should influence the decision to map to a custom value.

  • Reported: JAV2I 1.0b1 — Fri, 16 Oct 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Container/member name clashes

  • Key: JAV2I13-14
  • Legacy Issue Number: 3200
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    There is a commonly occurring name collision that is not covered by the
    current name mangling rules. This is demonstrated by the Java to IDL mapping
    of java.util.Date. The IDL generated gives a custom valuetype "Date" which
    contains an attribute "date", which is illegal in IDL. This problem is not
    unique to java.util.Date.

    More generally, this collision occurs whenever a Java interface or class
    being mapped to IDL contains a method or data member with the same name
    as the interface or class (using a case-insensitive comparison). For example,
    the following Java definitions cause this problem:

  • Reported: JAV2I 1.0b1 — Sun, 9 Jan 2000 05:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of serialVersionUID field

  • Key: JAV2I13-13
  • Legacy Issue Number: 3160
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Does the serialVersionUID field need to be private, static, and final,
    or just static and final? The Java to IDL spec says private, static,
    and final, but as far as I can tell, regular Java serialization just
    uses static and final. This has been a source of confusion for a number
    of users.

  • Reported: JAV2I 1.0b1 — Wed, 22 Dec 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Boolean attributes

  • Key: JAV2I13-12
  • Legacy Issue Number: 3118
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Thought I would raise this as a formal issue.

    The spec is ambiguous about mapping boolean accessors when in the following cases

    boolean isFoo ();
    void setFoo(boolean x);

    and

    boolean getBar();
    boolean isBar();
    void setBar(boolean x);

    According to the spec, both of the above get mapped to attributes. But, an attribute has only one getter and one setter.
    So, the question is what is isBar represented as on the wire? And how is the distinction made between isBar and getBar?

    Two ideas I can think of are
    1. Drop isBar from being recognized as a getter for attribute bar.
    2. Have isBar be represented on the wire as _get_bar. This has the effect of the two methods collapsing into
    one on the receiving context, which is probably OK because they should semantically be equivalent anyway.

  • Reported: JAV2I 1.0b1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PortableRemoteObject.narrow(null)

  • Key: JAV2I13-11
  • Legacy Issue Number: 3093
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The spec does not define what happens when a null object reference is passed to
    PortableRemoteObject.narrow(). For consistency with xxxHelper.narrow(), I think
    it should return null.

  • Reported: JAV2I 1.0b1 — Tue, 7 Dec 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping of Java constructors to init is broken

  • Key: JAV2I13-10
  • Legacy Issue Number: 2565
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Java to IDL mapping specifies that Java constructors are
    mapped to IDL initializers. Now that core RTF issue 1981 has
    replaced IDL initializers by factory methods, this mapping is
    broken and inconsistent with the core chapters.

  • Reported: JAV2I 1.0b1 — Wed, 31 Mar 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Name mapping rules for non-ASCII characters

  • Key: JAV2I13-9
  • Legacy Issue Number: 5772
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Section 1.3.2.4 of the Java to IDL Mapping spec describes name mapping rules
    for illegal IDL identifier characters. The text implies that only non-Latin 1
    characters are illegal, but in fact non-ASCII characters are illegal in IDL
    identifiers (see section 3.2.3 of the CORBA spec).

    Proposed resolution:

    In section 1.3.2.4, change "outside of ISO Latin 1" to "outside of ASCII".

  • Reported: JAV2I 1.2 — Fri, 29 Nov 2002 05:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    In section 1.3.2.4, change "outside of ISO Latin 1" to "outside of ASCII".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

scheme for mapping names is pretty byzantine

  • Key: JAV2I13-8
  • Legacy Issue Number: 5742
  • Status: closed  
  • Source: Boeing ( Paul Murray)
  • Summary:

    You know, this scheme for mapping names is pretty byzantine. As far as I can tell, if you happen to name a java variable J_Fred, you've got problems. I'm sure you get plenty of suggestions. Here's mine:

    1) Underscore is used consistently as an escape character. Thus: _ -> __ $ -> _S \u1234 -> _U1234 ( -> _P (parenthesis) [ -> _B (bracket) ; -> _C (semiColon) / -> _F (forward slash)

    _U uppercases a single character doRecord -> DO_URECORD

    A indicates that the entire name is in uppercase MAX_VALUE -> _AMAX_VALUE

    2) inner classes - we replace the dot with a $, and use that as the name. This is how most java compilers produce inner classes.

    3) Overloaded names - In the case of overloaded names, then rather than using the simple name of a method or variable, we use the converted name as it is defined in the java virtual machine specification, section 4.3. This is an already existing standard for uniquely identifying members in java classes. As methods are identified by parameters (ie: we don't need the return types to distinguish them), we can ignore the closing parenthesis and return type of a Method Descriptor.

    However, we use lowercase for the characters in table 4.2 so that our underscore escaping doesn't expand out foo(I to foo_P_UI

    thus: int FOO int foo void foo() Object foo(int) long foo(int[]) a.b.Boz foo(a.b.Bar.Baz)

    become

    FOO foo foo( foo(i foo([i foo(la/b/Bar$Baz;

    which are encoded by the rules above to

    _AFOO FOO FOO_P FOO_PI FOO_P_BI FOO_PLA_FA_F_UBAR_S_UBAZ_C

    These are not very natural ... but there you go. Serves you right for attempting to use IDL for overloaded names.

    If IDL had an name ailiasing facility (maybe it does), then all classes and methods could be generated as above and used as such in generated code, and an alias produced for those names which map unambiguously to a particular field or value.

    Thus for doAThing(int), all generated code would use DO_UA__UTHING_PI, but an alias DOATHING would be generated and presumably used by coders.

  • Reported: JAV2I 1.2 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

1.2.3 RMI/IDL Remote Interfaces 2

  • Key: JAV2I13-7
  • Legacy Issue Number: 5741
  • Status: closed  
  • Source: Boeing ( Paul Murray)
  • Summary:

    1.2.3 RMI/IDL Remote Interfaces 2. All methods in the interface are defined to throw java.rmi.RemoteException or a superclass of java.rmi.RemoteException.

    Should this read " ... or a subclass of ..." as per point 4 and elsewhere?

  • Reported: JAV2I 1.2 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with ValueHandler.getRunTimeCodeBase and PRO.exportObject

  • Key: JAV2I13-6
  • Legacy Issue Number: 5723
  • Status: closed  
  • Source: Borland Software Corporation ( Cuie Zhao)
  • Summary:

    1. The Java to IDL mapping spec defines the ValueHandler.getRunTimeCodeBase() that returns an CORBA object reference of SendingContext::RunTime to be used to construct the SendingContextRunTime service context:

    org.omg.SendingContext.RunTime getRunTimeCodeBase();

    However, the ValueHandler is not ORB aware of, how should the object reference be constructed by the ValueHandler? More specifically, how should the ValueHandler get a handle of a POA and which POA to create the reference?

    2. Similar issue exists in PortableRemoteObject.exportObject() and PRO constructor:

    protected PortableRemoteObject() throws java.rmi.RemoteException;
    public static void exportObject(java.rmi.Remote obj) throws java.rmi.RemoteException;

    The spec says:

    "Server side implementation objects may either inherit from javax.rmi.PortableRemoteObject or they may simply implement an RMI/IDL remote interface and then use the exportObject method to register themselves as a server object"

    The PRO is again not ORB aware of, how should the remote object be exported and registered with a POA and with which POA?

    3. The spec needs to clearly indicate on who owns the creation/initialization of the ORB. Should rmi-iiop implementation implicitly create/initialize an ORB instance at some point of time? Or should the RMI-IIOP application create/initialize an ORB instance and pass into the RMI-IIOP implementation via certain APIs?

  • Reported: JAV2I 1.2 — Fri, 25 Oct 2002 04:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    Closed, accepted. See revised text below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Java Codebase tagged component and POA

  • Key: JAV2I13-5
  • Legacy Issue Number: 5454
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    The Java to IDL specification uses the IOR TaggedComponent
    TAG_JAVA_CODEBASE to transmit a codebase string used to download stubs
    and ties. Yet, at IOR creation time when using the POA, the ORB may
    not know the implementing servant, so may not be able to determine the
    correct codebase.

    I propose solving this by the creationg of a standard POA Policy for
    the Java codebase component. A POA using this policy will add the
    given codebase string as the TAG_JAVA_CODEBASE component in the IORs
    which it creates. (Someone using a single given POA for supporting
    multiple servant types would of course have to include the codebases
    for all of them.)

    Proposed resolution:

    1. Add a section in CORBA 11.3.7:

    11.3.7.x Java Codebase Policy

    Objects with the JavaCodebasePolicy interface are obtained using the
    ORB::create_policy operation and passed to the POA::create_POA
    operation to specify the TAG_JAVA_CODEBASE TaggedComponent's value
    that should be used in this POA's IORs. The any passed to
    ORB::create_policy should contain a string which is a space-separated
    list of one or more URLs, as described in the Java to IDL mapping
    (formal/01-06-07), Codebase Transmission.

    2. Add the following to the IDL in CORBA 11.4:

    const CORBA::PolicyType JAVA_CODEBASE_POLICY_ID = nn;
    [note to editor: number to be assigned by OMG]

    local interface JavaCodebasePolicy : CORBA::Policy

    { readonly attribute string codebase; }

    ;

  • Reported: JAV2I 1.2 — Tue, 9 Jul 2002 04:00 GMT
  • Disposition: Resolved — JAV2I 1.3
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT