Java to IDL Language Mapping Avatar
  1. OMG Specification

Java to IDL Language Mapping — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
JAV2I12-101 PortableRemoteObject toStub should throw NoSuchObject Exception JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-100 Mapping of Java names that are IDL keywords JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-68 RMI/ORB marshalling interface JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-69 javax.rmi package use JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-66 Custom marshalling wire format JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-64 Mapping of RuntimeException JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-67 Mapping of Object, Serializable and Externalizable JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-65 The mapping of java.lang.Class to IDL is not specified JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-63 Specifying code downloading JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-60 Mapping of java.rmi remoteException superclasses JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-59 Mapping of non-public types JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-62 Eliminating server wait code JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-61 Mapping of Java arrays JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-58 Need overloaded write_Value method on OutputStream JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-56 Need to #include orb.id JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-54 Local stubs proposal JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-57 Value methods not mapped in spec examples JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-55 JTS exceptions JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-52 Java to IDL identifier mapping JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-50 Stub methods for hashCode, equals and toString JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-49 Omission in section 5.4.5 JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-53 read_AbstractObject and write_AbstractObject JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-48 Abstract Interfaces issue JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-51 Should Portability APIs throw SystemException? JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-47 Should exportObject throw exceptions? JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-45 Do we need to protect non-generated IDL files against multiple inclusion? JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-41 Does toStub return most derived stub? JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-44 mangling rule for name clashes in IDL needs to be defined JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-46 Rules in section 7.4.4 for toStub IIOP/JRMP search not correct JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-43 The generated IDL in A2 needs to be changed JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-42 Clarify rules for mapping server-side errors and exceptions JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-39 Section 5.7.4 : mapped IDL issue JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-38 Narrow signature does not allow use for abstract interfaces JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-40 Can toStub take a stub? JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-36 Need to emit ID pragmas after declarations JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-35 Mapping for nested sequences --- fix example JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-37 Lexigraphic sort for field names is before mangling JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-32 Obtaining a default ORB JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-33 SerializationInputStream and SerializationOutputStream JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-34 Unicode example needs fixing JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-31 How to make IDLEntity types serializable JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-30 Default Constructor for Stubs JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-29 Marshalling of Any, Context, Principal, and TypeCode JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-28 orb() method on InputStream JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-27 Public method declarations in ResponseHandler interface JAV2I 1.0b1 JAV2I 1.0 Resolved closed

Issues Descriptions

PortableRemoteObject toStub should throw NoSuchObject Exception

  • Legacy Issue Number: 1610
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: PortableRemoteObject.toStub should throw NoSuchObjectException if object
    has not been exported.

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 14:01 GMT

Mapping of Java names that are IDL keywords

  • Legacy Issue Number: 1641
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Java to IDL mapping spec says that a Java name that is an IDL
    keyword is mapped to a mangled name consisting of the IDL keyword
    followed by a trailing underscore. Now that the Objects By Value
    RTF has adopted escaped identifiers with keading underscores, we
    should revise this mapping to use escaped identifiers.
    I propose that section 5.2.2 of the Java to IDL mapping spec be
    changed to state that Java names that collide with IDL keywords
    are mapped to IDL by adding a leading underscore, so that typedef
    would be mapped to _typedef.

  • Reported: JAV2I 1.0b1 — Wed, 8 Jul 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 02:44 GMT

RMI/ORB marshalling interface

  • Key: JAV2I12-68
  • Legacy Issue Number: 2092
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The ORB should be responsible for marshalling all value headers and
    other protocol specific data. The RMI runtime should only marshal
    the state of the object. In other words, we exepect the contract
    between the ORB and RMI to be the similar to that of the ORB and
    an IDL generated ValueHelper.

    • The APIs should allow all RMI types supported by the IDL-Java mapping
      to be marshalled completely and correctly.
    • The APIs should be flexible enough to allow for some change in either
      RMI/Serialization semantics or changes to OBV wire protocol.
  • Reported: JAV2I 1.0b1 — Fri, 16 Oct 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    Closed, accepted

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

javax.rmi package use

  • Key: JAV2I12-69
  • Legacy Issue Number: 2225
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It has concerned me for a while the use of the javax.rmi package in the Java
    to IDL mapping. I think that PortableRemoteObject and other classes should be
    placed in a subpackage. We may in the future put subpackages in javax.rmi and
    would like it organized much better than it is currently. The
    PortableRemoteObject class should be put in a subpackage "portable" or
    something else. I"d like to raise this as an issue to discuss at the RTF.
    There are still other issues that are being ironed out, and I think that this
    one can be addressed along with the others.

  • Reported: JAV2I 1.0b1 — Thu, 19 Nov 1998 05:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    Closed, no change

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

Custom marshalling wire format

  • Key: JAV2I12-66
  • Legacy Issue Number: 2089
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The full wire format produced by ObjectOutputStream really needs
    to be specified. E.g., I would assume that anything written with
    writeObject gets marshalled as an Any. In normal Java
    serialization, consecutive primitive writes (writeByte, writeInt,
    etc.) are aggregated into chunks with size lengths, and tagged
    to distinguish it from other data. In this way, ObjectInputStream
    can ensure that major stream corruption never occurs: it can
    make sure that a primitive read never eats into object data,
    and vice versa. Is a similar format used for IIOP?

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

    Closed, accepted

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

Mapping of RuntimeException

  • Key: JAV2I12-64
  • Legacy Issue Number: 2082
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If a Java method explictly declares that it throws RuntimeException or
    some subclass, the current spec says that these should be retained in
    the mapping to IDL. I think this is wrong; they should be dropped
    when mapping to IDL. The reasoning is along the same lines as dropping
    subclasses of RemoteException.

  • Reported: JAV2I 1.0b1 — Wed, 14 Oct 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Mapping of Object, Serializable and Externalizable

  • Key: JAV2I12-67
  • Legacy Issue Number: 2090
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The proposal here is to map Object, Serializable and Externalizable
    to distinct entities, rather than just to an any.

    These entities are
    module java {
    module lang

    { typedef any _Object; }

    ;
    module io

    { typedef any Serializable; typedef any Externalizable; }

    ;
    };

    and so
    java.lang.Object will map to ::java::lang::_Object,
    java.io.Serializable will map to ::java::io::Serializable, and
    java.io.Externalizable will map to ::java::io.Externalizable

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

    No Data Available

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

The mapping of java.lang.Class to IDL is not specified

  • Key: JAV2I12-65
  • Legacy Issue Number: 2088
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The mapping of java.lang.Class to IDL is not specified. An
    interesting subquestion is whether it"s possible to transmit a
    Class that has not previously been mapped to IDL.

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

    No Data Available

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

Specifying code downloading

  • Key: JAV2I12-63
  • Legacy Issue Number: 2081
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec should mandate codebase annotation when marshalling in Java,
    and should specify how the annotation is selected.

    The spec should mandate code downloading using the codebase annotation
    when demarshalling in Java, and should specify the classloader semantics.

  • Reported: JAV2I 1.0b1 — Wed, 14 Oct 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    Closed, accepted

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

Mapping of java.rmi remoteException superclasses

  • Key: JAV2I12-60
  • Legacy Issue Number: 1958
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is an issue with the currently specified mapping for Java
    remote and abstract interfaces containing methods that throw
    superclasses of java.rmi.RemoteException but do not throw
    java.rmi.RemoteException. In Java 1.1, these are not recognized
    as RMI remote interfaces. In Java 1.2, these are recognized as
    RMI remote interfaces.

    I propose that throwing these superclass exceptions be treated by
    the Java to IDL mapping as semantically equivalent to throwing
    both RemoteException and the superclass exception. This means
    that the section 4.3 rules for RMI/IDL remote interfaces would
    be changed to include this case (in point 3), with similar changes
    elsewhere in the spec.

  • Reported: JAV2I 1.0b1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Mapping of non-public types

  • Key: JAV2I12-59
  • Legacy Issue Number: 1957
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec needs to say what happens if a Java public RMI/IDL
    value class has data members whose types are not public.

    Options: Either a) restrict all uses of non-public types, or
    b) map all non-public types to public in IDL.

    Inprise have proposed that we adopt option b). Comments?

  • Reported: JAV2I 1.0b1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Eliminating server wait code

  • Key: JAV2I12-62
  • Legacy Issue Number: 1965
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: An RMI-JRMP server creates and exports server objects and then
    returns. A non-daemon thread created by the JRMP runtime keeps the
    server process alive until there are no more objects exported.
    For code portability, an RMI-IIOP server needs to work in a similar
    way. It is not acceptable to require a call to ORB.run() or the
    use of application "wait" code to keep the server process alive.

    I propose that the specification of PortableRemoteObject.exportObject
    be updated to say that the first call to this creates a non-daemon
    thread which keeps the JVM alive until all exported objects have
    been unexported by calls to PortableRemoteObject.unexportObject.

  • Reported: JAV2I 1.0b1 — Wed, 16 Sep 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Mapping of Java arrays

  • Key: JAV2I12-61
  • Legacy Issue Number: 1960
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Generated names in the ::org::omg::sequences module can clash.
    For example, a Java array of type foo[][] and a Java array of type
    seq_foo[] both map to ::org::omg::sequences::seq_seq_foo.

    I propose that instead of using repeated "seq_" prefixes for the
    array dimensions, a single prefix "seq<n>_", where <n> is the
    number of dimensions, should be used. This ensures no clashes.
    In the example above, these Java types would map to seq2_foo and
    seq1_seq_foo.

  • Reported: JAV2I 1.0b1 — Wed, 16 Sep 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Need overloaded write_Value method on OutputStream

  • Key: JAV2I12-58
  • Legacy Issue Number: 1931
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Suppose we are passing an array of declared type Animal[] and
    runtime type Wombat[] but whose elements are all of runtime type
    Wombat, where Wombat is a subtype of Animal. This array is mapped
    to a boxed valuetype in the org.omg.sequences module. In the
    RMI-IIOP stub, we need to write this array by making a write_Value
    call (so that sharing can be handled correctly). The repository ID
    that we need to write is for a type seq_Animal, based on a static
    mapping from the declared type of the array (see section 5.6 of the
    Java-to-IDL spec). However, if the stub used the normal write_Value
    call that takes a single argument of the object to be written, the
    runtime will not be able to put the correct repository ID on the
    wire because it only knows about the runtime type of the array, not
    the declared type. For the IDL case, this is taken care of by
    having the stub generate the form of write_Value that takes a
    ValueHelper object for the declared type, but in RMI-IIOP there are
    no ValueHelper objects.

  • Reported: JAV2I 1.0b1 — Thu, 3 Sep 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    closed, accepted

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

Need to #include orb.id

  • Key: JAV2I12-56
  • Legacy Issue Number: 1891
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The example in section A.2 of the Java-to-IDL spec uses the
    type ::CORBA::WStringValue but does not define this type.
    By CORBA convention, the definition will be in the file
    orb.idl, which should be #included in the example IDL code.
    I propose that this example be changed to #include orb.idl.
    l

  • Reported: JAV2I 1.0b1 — Wed, 26 Aug 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    :CORBA::WStringValue but does not define this type.

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

Local stubs proposal

  • Key: JAV2I12-54
  • Legacy Issue Number: 1736
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is currently no standard support for local RMI/IDL stubs.
    In contrast, the IDL/Java mapping specifies how support for local
    stubs is to be provided. The Java to IDL mapping should also
    specify standard APIs for local stubs which are compatible with
    the POA and the mechanisms used by IDL/Java local stubs.

  • Reported: JAV2I 1.0b1 — Mon, 27 Jul 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    closed, accepted

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

Value methods not mapped in spec examples

  • Key: JAV2I12-57
  • Legacy Issue Number: 1894
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Java to IDL mapping spec specifies rules for how value
    methods are mapped to IDL. However, none of the examples
    shows any of these methods actually being mapped. Although
    this is legal according to the spec, it has led to some
    confusion as to which methods would normally be expected to
    be mapped, such as the writeObject method in section 5.5.9.

  • Reported: JAV2I 1.0b1 — Thu, 27 Aug 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

JTS exceptions

  • Key: JAV2I12-55
  • Legacy Issue Number: 1780
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Java-to-IDL spec says in section 6.6.1 that certain CORBA system
    exceptions are mapped to the Java exceptions
    javax.jts.TransactionRequiredException
    javax.jts.TransactionRolledBackException
    javax.jts.InvalidTransactionException

    The names above are obsolete (since Sun revised the JTS/JTA specs),
    so the Java-to-IDL spec needs to be changed. Possible mappings are:
    1. javax.transaction.<the_same_names_as_above>
    (as listed in the JTA spec)
    2. java.rmi.RemoteException
    3. No mapping (leave them as CORBA system exceptions)

    Option 1 implies a dependency of the RMI-IIOP runtime on these
    JTA exception classes.

  • Reported: JAV2I 1.0b1 — Thu, 6 Aug 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Java to IDL identifier mapping

  • Key: JAV2I12-52
  • Legacy Issue Number: 1642
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: orbos/98-02-01 says:

    We have provided name manglings to work around [the limitations],
    but we recommend that OMG consider extending the definitions of
    IDL identifiers so that a wider range of unicode characters can
    be supported and so that case is significant in distinguishing
    identifiers.

    I would suggest to remove this recommendation because it is pragmatically
    unimplementable for implementation languages that do not support
    extended character sets. If the OMG were to take this step, it would
    effectively alienate CORBA from all such implementation languages, which
    I believe would be detrimental to the success of CORBA.

    Because overloaded methods are a popular feature in object-oriented
    programming languages we recommend that OMG considers extending
    IDL to allow overloaded methods.

    Again, I suggest to remove the recommendation because it is pragmatically
    unimplementable. Steve Vinoski recently posted an interesting article
    on this topic in comp.object.corba – I have attached a copy below.

  • Reported: JAV2I 1.0b1 — Wed, 8 Jul 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Stub methods for hashCode, equals and toString

  • Key: JAV2I12-50
  • Legacy Issue Number: 1621
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: RMI/JRMP stubs provide overridden implementations for the
    hashCode, equals, and toString methods of java.lang.Object.

    The stub hashCode method returns the same hash code for
    different stubs that refer to the same remote object.
    The stub equals method returns true when stubs that refer
    to the same remote object are compared. These methods allow
    remote objects to be held in Java collections.

    The stub toString method returns a string containing information
    about the remote object, not the local stub.

    RMI/IIOP stubs should provide equivalent methods. The easiest
    way to do this is to add implementations of these three methods
    to the javax.rmi.CORBA.Stub base class.

    I propose that the definition of javax.rmi.CORBA.Stub in
    section 7.2.5 be modified to add these methods.

  • Reported: JAV2I 1.0b1 — Tue, 30 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Omission in section 5.4.5

  • Key: JAV2I12-49
  • Legacy Issue Number: 1620
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The text in section 5.4.5 has no mention of String constants.
    This seems to be an accidental omission. I propose replacing
    the text in this section by the text in section 5.5.5, with
    "value type" changed to "interface".

  • Reported: JAV2I 1.0b1 — Tue, 30 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

read_AbstractObject and write_AbstractObject

  • Key: JAV2I12-53
  • Legacy Issue Number: 1662
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 7.1.2, there is a method called read_AbstractObject(clz).
    I propose that we change its name to read_Abstract to bring it
    into line with the read_Abstract() method introduced in section
    8.7.1 of the OBV spec. This is consistent with having methods
    called read_Object() and read_Object(clz).

    There"s also a typo in section 7.2.6. It says that
    Util.write_AbstractObject calls OutputStream.write_AbstractObject.
    This should say OutputStream.write_Abstract.

  • Reported: JAV2I 1.0b1 — Fri, 10 Jul 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Abstract Interfaces issue

  • Key: JAV2I12-48
  • Legacy Issue Number: 1619
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current Java to IDL mapping spec does not fully address support
    for abstract interfaces. There is support for these in the
    Portability Interfaces chapter, but not in the RMI/IDL Subset or
    IDL Mapping chapters.

  • Reported: JAV2I 1.0b1 — Tue, 30 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Should Portability APIs throw SystemException?

  • Key: JAV2I12-51
  • Legacy Issue Number: 1640
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
    concern to the IDL-to-Java RTF because it affects the IDL-to-Java
    mapping.

    Three of the new portability APIs intorduced by the Java to IDL mapping
    are declared as throwing org.omg.CORBA.SystemException. These are
    the _invoke methods of ObjectImpl and Delegate and the _invoke method
    of InvokeHandler. I don"t think this exception hould be declared
    explicitly, since it is a subclass of java.lang.RuntimeException and so
    is always implictly throwable whether it is declared or not. Also,
    other portability APIs can throw this exception even though they do not
    declare it explicitly. This inconsistency makes it very difficult for
    the reader of the spec to determine which of the portability APIs can
    throw CORBA system exceptions, and is likely to cause confusion.

    I propose that org.omg.CORBA.SystemException be removed from the throws
    clause of the above-mentioned APIs.

  • Reported: JAV2I 1.0b1 — Wed, 8 Jul 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Should exportObject throw exceptions?

  • Key: JAV2I12-47
  • Legacy Issue Number: 1609
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 25. Should exportObject throw exceptions?

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Do we need to protect non-generated IDL files against multiple inclusion?

  • Key: JAV2I12-45
  • Legacy Issue Number: 1607
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Do we need to protect non-generated IDL files against multiple
    inclusion?

    Proposed resolution: no protection

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Does toStub return most derived stub?

  • Key: JAV2I12-41
  • Legacy Issue Number: 1602
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 15. does toStub return most derived stub, or iterate looking for one?

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

mangling rule for name clashes in IDL needs to be defined

  • Key: JAV2I12-44
  • Legacy Issue Number: 1606
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Need to define a mangling rule for name clashes in IDL between
    constant/method/attribute.

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Rules in section 7.4.4 for toStub IIOP/JRMP search not correct

  • Key: JAV2I12-46
  • Legacy Issue Number: 1608
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Rules in section 7.4.4 for toStub IIOP/JRMP search aren"t quite correct.
    If the object has been exported as IIOP (i.e., an IIOP Tie exists),
    no attempt will be made to create a JRMP stub even if there is no IIOP
    stub class.

    Proposed resolution: clarify spec

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

The generated IDL in A2 needs to be changed

  • Key: JAV2I12-43
  • Legacy Issue Number: 1604
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The generated IDL in A2 needs to be changed.

    In particular, forward declares for fred.Test2 and fred.Stuff must
    appear before #includes, before sequence defs and before the module
    definition. Their #includes must appear at the end. In fact, just follow
    the file layout rules described at the beginning of the appendix.

    If this is not done, there is a danger that circular references will
    lead to undeclared types when the IDL is compiled.

    Proposed resolution: fix example

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Clarify rules for mapping server-side errors and exceptions

  • Key: JAV2I12-42
  • Legacy Issue Number: 1603
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 17. Need to clarify rules for mapping server-side errors and runtime
    exceptions back to client exceptions.

    Proposed resolution: use omg.omg.CORBA.UNKNOWN

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Section 5.7.4 : mapped IDL issue

  • Key: JAV2I12-39
  • Legacy Issue Number: 1600
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 5.7.4 the mapped IDL for Thrower includes:
    FruitbatException getLastException();
    It should be
    readonly attribute ::omega::FruitbatException lastException;

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Narrow signature does not allow use for abstract interfaces

  • Key: JAV2I12-38
  • Legacy Issue Number: 1599
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 12. Narrow signature does not allow use for abstract interfaces

    Proposed resolution: return java.lang.Object

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Can toStub take a stub?

  • Key: JAV2I12-40
  • Legacy Issue Number: 1601
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Can toStub take a stub?

    Proposed resolution: yes, in which case it"s a no-op.

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Need to emit ID pragmas after declarations

  • Key: JAV2I12-36
  • Legacy Issue Number: 1597
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 10. Need to emit ID pragmas after declarations

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Mapping for nested sequences --- fix example

  • Key: JAV2I12-35
  • Legacy Issue Number: 1596
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: mapping for nested sequences:

    • error in section 5.6 sequence<seq_Y>
    • no occurrence of >> so no need for white space

    Proposed resolution: fix example in section 5.6

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Lexigraphic sort for field names is before mangling

  • Key: JAV2I12-37
  • Legacy Issue Number: 1598
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Lexigraphic sort for field names is before mangling

    Proposed resolution: clarify section 5.5.6

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Obtaining a default ORB

  • Key: JAV2I12-32
  • Legacy Issue Number: 1593
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
    concern to the IDL-to-Java RTF because it affects the IDL-to-Java
    mapping.

    There are two places in the Java to IDL mapping spec that imply
    the use of a default ORB. One is the toStub method of the
    PortableRemoteObject class, and the other is the readObject method
    of the javax.rmi.CORBA.Stub class. It is not clear how we can
    obtain a suitable default ORB for use in these APIs without either
    excessive resource consumption (if we start a new ORB every time)
    or violating applet isolation boundaries (if we use the same ORB
    every time).

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    Closed, accepted

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

SerializationInputStream and SerializationOutputStream

  • Key: JAV2I12-33
  • Legacy Issue Number: 1594
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
    concern to the Objects By Value RTF because it affects the Java
    ORB implementation of Objects By Value.

    The currently specified delegation relationship between
    SerializationInputStream and SerializationOutputStream and their
    underlying ORB stream classes is inefficient and awkward.
    It is awkward because it requires the ORB implementation of the
    underlying streams to know about their "wrapper" serialization
    streams and to be careful to always pass out a reference to the
    wrapper instead of a "this" pointer. It is inefficient because
    all items (even primitives) that are written to these streams
    need to go through an extra delegation step through the wrapper
    class as the underlying stream does not know whether it can
    safely bypass the wrapper method.

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Unicode example needs fixing

  • Key: JAV2I12-34
  • Legacy Issue Number: 1595
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Unicode example given in the spec (5.2.4) is x\u22aBy
    javac diagnoses \u22aB as an invalid character in an identifier.

    A Java identifier may only consist of Unicode characters that denote a
    letter or a digit in a language. \u22aB (apparently) does not.

    Try \u03bC instead. According to 8.2.1 it"s a Greek mu. javac is happy
    with it.

    Proposed resolution: fix example

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

How to make IDLEntity types serializable

  • Key: JAV2I12-31
  • Legacy Issue Number: 1592
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
    concern to the IDL-to-Java RTF because it affects the IDL-to-Java
    mapping.

    The Java to IDL mapping spec states that Java types produced by
    the direct mapping should implement IDLEntity and be serializable.
    This could be accomplished by having IDLEntity extend
    Java.io.Serializable, or by having the generated types extend
    both IDLEntity and java.io.Serializable. The spec should
    specify which of these approaches is to be used.

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Default Constructor for Stubs

  • Key: JAV2I12-30
  • Legacy Issue Number: 1591
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
    concern to the IDL-to-Java RTF because it affects the IDL-to-Java
    mapping.

    When adding support for idlToJava generated Stubs to
    "InputStream.read_Object(java.lang.Class clz)" we ran into a small
    problem while writing the code. Initially we used "clz.newInstance()"
    to create an instance of the Stub object. The problem here is the
    Stub does not have a default constructor, so newInstance throws an
    exception. We added a default constructor to the stub and everything
    worked fine. The question is: should we add a default constructor to
    the stubs generated by idlToJava or should we use reflection(cost??) to
    invoke the one constructor that is already a member of the stub class?

    I propose that we state in the spec that a default constructor is
    required on all generated Stubs.

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Marshalling of Any, Context, Principal, and TypeCode

  • Key: JAV2I12-29
  • Legacy Issue Number: 1590
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
    concern to the IDL-to-Java RTF because it affects the IDL-to-Java
    mapping.

    How do SerializationInputStream and SerializationOutputStream marshal
    Any, Context, Principal, and TypeCode objects? Is the same mechanism
    used as for user-defined IDL types, i.e., look for the IDLEntity
    marker interface and call the implementation helper class"s write
    or read method? If so, we need to clarify that vendor implementation
    of these types must implement IDLEntity and provide a Helper class.

    I propose that we state in the spec that vendor implementations of
    these types must implement IDLEntity and provide a Helper class.

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

orb() method on InputStream

  • Key: JAV2I12-28
  • Legacy Issue Number: 1589
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This item affects the Java-to-IDL spec, but is also of concern to the
    IDL-to-Java RTF because it relates to the new portability stub APIs.

    An orb() method is needed on org.omg.CORBA.portable.InputStream for
    SerializationInputStream to call to find which ORB to use for
    lookup_value_factory during execution of read_Value.

    I propose adding an orb() method to org.omg.CORBA.portable.InputStream.

  • Reported: JAV2I 1.0b1 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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

Public method declarations in ResponseHandler interface

  • Key: JAV2I12-27
  • Legacy Issue Number: 1578
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This item affects the Java-to-IDL spec, but is also of concern to the
    IDL-to-Java RTF because it relates to the new portability stub APIs.

    Section 7.2.2 of the Java to IDL mapping specifies a new interface
    ResponseHandler with methods createReply and createExceptionReply.
    These methods are declared as public.

    Section 9.4 of the Java Language Specification states that "Every
    method declaration in the body of an interface is implicitly public.
    It is permitted, but strongly discouraged as a matter of style, to
    redundantly specify the public modifier for interface methods."

    I propose that the public modifier be removed from these method
    declarations.

  • Reported: JAV2I 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.0
  • Disposition Summary:

    No Data Available

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