Java to IDL Language Mapping Avatar
  1. OMG Specification

Java to IDL Language Mapping — All Issues

  • Acronym: JAV2I
  • Issues Count: 42
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
JAV2I12-103 stub classes can violate licensing and package sealing JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-102 Security problem in JavaToIDL mapping JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-97 $issue.summary JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-95 $issue.summary JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-96 $issue.summary JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-94 mapping of java.lang.Exception JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-93 Mapping remote interface types to RMI-style repository IDs JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-92 ::java::lang::Exception is illegal IDL JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-91 Misleading wording in section 28.5.1.4 JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-90 Need getTarget method on Tie interface JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-87 Mapping of java.rmi.Remote JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-89 Need read_Value(clz) on InputStream JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-88 NotSerializableException for RMI-IIOP JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-84 Use of "java" as top-level IDL module JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-83 Replaceability of javax.* APIs JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-82 RMI Repository ID proposed change JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-86 mapSystemException should preserve original exception JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-85 export/unexport errors not well specified JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-81 IDLEntity types need to be boxed JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-80 Definition of Stub.equals method JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-79 Mapping for non-conforming class JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-78 Mappings for non-conforming types JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-77 Interfaces and values should be mapped consistently JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-76 RMI/IDL Tie changes JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-75 Completion status missing from exception string JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-72 Change write_* names in Util class JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-74 IDLEntity exception types as parameters and results JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-73 IIOP/JRMP stubs name clash JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-70 Mangling of Java long type not specified JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-71 Mapping private Java methods to IDL JAV2I 1.0 JAV2I 1.1 Resolved closed
JAV2I12-15 Tie.deactivate() exception handling JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-13 Name mangling scheme broken. JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-12 mapping from java.rmi Remote to CORBA::Object JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-24 Mapping of CORBA any and TypeCode JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-23 Package for PortableRemoteObjectDelegate JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-22 Descriptions of readAny and writeAny not precise enough JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-21 ValueHandler Interface JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-19 Exception mapping needs fixing JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-17 loader.loadClass() or Class.forName()? JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-16 No factory for javax.rmi.ClassDesc JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-26 Mapping of Java byte constants to IDL JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-25 Mapping CORBA minor codes to Java JAV2I 1.0b1 JAV2I 1.1 Resolved closed

Issues Descriptions

stub classes can violate licensing and package sealing

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

    Summary: Placing generated stub classes in the package in which the interface is defined
    is flawed for a few reasons:

    1) It can violate license agreements (e.g., Jini uses remote interfaces, and
    if an RMI-IIOP stub is generated from one of the core Jini interfaces
    the license agreement will be violated since a new public class
    will be added to the core).

    2) Placing generated classes in the same package as the remote interface
    definition will not be possible if the package is sealed.

    If an interface is public, such generated classes could be placed in a
    sub-package of a CORBA-specific package, for example,
    org.omg.CORBA.stub.java.rmi._Remote_Stub.

  • Reported: JAV2I 1.0 — Thu, 15 Jul 1999 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 14:03 GMT

Security problem in JavaToIDL mapping

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

    Summary: We have a security hole in the reverse mapping that can be fixed by a
    straight forward spec change.

    The Java-to-IDL mapping spec 99-03-09 defines in paragraph 28.4.9.5 that
    rmi-iiop offer a method

    > Util.loadClass(String className, String remoteCodebase, Class
    loadingContext)
    > throws ClassNotFoundException

    { ... }
    >


    which does the following if everything else fails to load the desired
    class (on both JDK 1.1 and 1.2)


    > If a class was not successfully loaded by step 1, 2, or 3, and
    loadingContext
    > and loadingContext.getClassLoader() are both non-null, then call
    > loadingContext.getClassLoader().loadClass(className)


    By virtue of being a "public" core method as part of the rmi-iiop
    standard extension this mechanism essentially bypasses the "caller class
    loader" security check from Class.getClassLoader() by allowing arbitrary
    code to load a class using the class loader of any other class. The
    ClassLoader javadoc says to this effect.

    > Class loaders may typically be used by security managers to indicate
    > security domains.

    The fix for this situation is to change the signature of the above
    method to


    > Util.loadClass(String className, String remoteCodebase,
    ClassLoader loader)
    > throws ClassNotFoundException { ... }

    >

    so that the caller has to perform the necessary
    loadingContext.getClassLoader() call before calling this method. This
    way the callers security permissions are checked properly by the
    getClassLoader mechanism.

    So code that uses this API right now has to change from

    Util.loadClass(className, remoteCodebase, loadingContext)

    to

    Util.loadClass(className, remoteCodebase,
    loadingContext.getClassLoader())

    after this spec change.

  • Reported: JAV2I 1.0 — Mon, 20 Sep 1999 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    No Data Available

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

${issue.summary}

  • Key: JAV2I12-97
  • Legacy Issue Number: 2818
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: JAV2I 1.0 — Wed, 21 Jul 1999 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    resolved in XMI 1.1 RTF

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

${issue.summary}

  • Key: JAV2I12-95
  • Legacy Issue Number: 2810
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: JAV2I 1.0 — Fri, 16 Jul 1999 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    closed is XMI 1.1 RTF

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

${issue.summary}

  • Key: JAV2I12-96
  • Legacy Issue Number: 2816
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: JAV2I 1.0 — Wed, 21 Jul 1999 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    resolved in XMI 1.1 RTF

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

mapping of java.lang.Exception

  • Key: JAV2I12-94
  • Legacy Issue Number: 2545
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I took another look at 28.3.7.1, and I think that the current
    special-case mapping of java.lang.Exception is odd and unnecessary.
    It seems to me that the right thing to do is to simply remove this
    special case, and map it the same as any other exception. So,
    java.lang.Exception should map to a valuetype that has
    ::java::lang::Throwable as a superclass and no data fields, and to an
    IDL exception of ::java::lang::Ex (note that this exception is used in
    an example in 28.3.4.6). java.lang.Throwable should map to a valuetype
    that has no superclass and a private data field named detailMessage, and
    to an IDL exception of ::java::lang::ThrowableEx.

  • Reported: JAV2I 1.0 — Tue, 16 Mar 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

Mapping remote interface types to RMI-style repository IDs

  • Key: JAV2I12-93
  • Legacy Issue Number: 2535
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: RMI remote interface types are currently mapped to IDL interfaces without
    a #pragma ID, which means they have IDL-style repository IDs. This causes
    problems when trying to locate a "best match" RMI stub for an IOR that
    contains this format of repository ID. Because of the non-reversible
    manglings from Java interface names to IDL interface names (inner classes,
    leading underscores, and Unicode characters), there is no reliable
    demangling from the IDL-style repid in an IOR to an RMI stub class name.

    This can be fixed by using the RMI style of repid instead of the IDL style
    of repid when mapping RMI remote interfaces to IDL, just as we currently
    do for value types.

  • Reported: JAV2I 1.0 — Mon, 15 Mar 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

::java::lang::Exception is illegal IDL

  • Key: JAV2I12-92
  • Legacy Issue Number: 2505
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The ::java::lang::Exception type specified by the Java to IDL mapping
    is wrong. It should be ::java::lang::_Exception, since exception is
    an IDL keyword.

  • Reported: JAV2I 1.0 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

Misleading wording in section 28.5.1.4

  • Key: JAV2I12-91
  • Legacy Issue Number: 2504
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The wording of section 28.5.1.4 is misleading. It says that
    writeRemoteObject and writeAbstractObject can allocate ties. This
    is not incorrect, but it could be misinterpreted. In some
    implementations, a tie is allocated when an implementation object
    is exported, so this wording could be taken to imply that these
    methods do an "auto export" if an unexported object is passed in
    to these methods.

  • Reported: JAV2I 1.0 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

Need getTarget method on Tie interface

  • Key: JAV2I12-90
  • Legacy Issue Number: 2503
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The javax.rmi.CORBA.Tie interface has a setTarget method but no getTarget.
    It is sometimes necessary to be able to obtain the target object for a tie.
    POA ties provide this facility, and it should be added to RMI/IDL ties.

  • Reported: JAV2I 1.0 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

Mapping of java.rmi.Remote

  • Key: JAV2I12-87
  • Legacy Issue Number: 2482
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This issue was raised by Vijay Natarajan of Inprise.

    It appears that we need to do the same trick we used to distinguish
    between Anys, java.lang.Objects, Serializable etc

    We need to map java.rmi.Remote to be an alias of Object as in
    module java {
    module rmi

    { typedef Object Remote; }

    ;
    };

    This is to allow us to distinguish in IDL mapping between

    public interface hello implements java.rmi.Remote

    { void foo (java.rmi.Remote arg); void foo (org.omg.CORBA.Object arg); }

    w/o the aliasing, these methods cannot be mapped.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

Need read_Value(clz) on InputStream

  • Key: JAV2I12-89
  • Legacy Issue Number: 2484
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is possible for an RMI/IDL value class to contain an IDLEntity type
    that was mapped from an IDL valuetype. In this case, the GIOP
    encoding of the IDLEntity type sent by an IDL/Java or C++ application
    to an RMI-IIOP appplication may not contain type information (if the
    actual type is the same as the declared type).

    In order to allow the ValueHandler to demarshal these IDLEntity types,
    an additional API call such as read_Value(Class clz) in needed on the
    org.omg.CORBA.portable.InputStream class. This allows the ValueHandler
    to pass the expected class (which it knows) to the InputStream.

    For symmetry, a write_Value(java.io.Serializable obj, Class clz) method
    should be added to org.omg.CORBA.portable.OutputStream. This would
    allow RMI-IIOP marshalling to use the same optimized encoding for this
    case as is possible for C++ and IDL/Java.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

NotSerializableException for RMI-IIOP

  • Key: JAV2I12-88
  • Legacy Issue Number: 2483
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If a user passes a non-remote and non-serializable object to a remote
    method whose signature type is an abstract interface, the IBM/Sun
    implementation of RMI-IIOP currently returns a ClassCastException.

    It is not very obvious to the user what is causing this error.
    RMI-JRMP returns a NotSerializableException in this case, which is
    much easier for the user to interpret.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

Use of "java" as top-level IDL module

  • Key: JAV2I12-84
  • Legacy Issue Number: 2479
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Java to IDL mapping specifies a number of names in the IDL
    module "java". Examples are ::java::lang::Exception and
    ::java::lang::_Object. This can cause problems when mapping
    Java to IDL and then remapping the resulting IDL back to Java.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, no change

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

Replaceability of javax.* APIs

  • Key: JAV2I12-83
  • Legacy Issue Number: 2478
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The javax.* APIs in the Java to IDL mapping spec have not been
    designed to separate interface from implementation. For the RMI-IIOP
    standard extension, this is not a problem since the whole standard
    extension can be replaced by other vendors if necessary. However,
    when RMI-IIOP becomes part of the core, it may be necessary to permit
    other vendors to replace these implementations without replacing the
    APIs (as is currently the case for the ORB APIs and implementation).

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

RMI Repository ID proposed change

  • Key: JAV2I12-82
  • Legacy Issue Number: 2477
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For the scoped name component, it is far simpler to use the actual class
    name of the java class with all the invalid IDL characters unicode escaped.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

mapSystemException should preserve original exception

  • Key: JAV2I12-86
  • Legacy Issue Number: 2481
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The RemoteException returned by mapSystemException should preserve
    the original CORBA system exception as the detail field.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

export/unexport errors not well specified

  • Key: JAV2I12-85
  • Legacy Issue Number: 2480
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The text describing PortableRemoteObject does not describe the
    possible error cases very completely or precisely. 1. Change the paragraph:

    It is an error to call exportObject more than once for the same object.

    to the paragraph:

    It is an error to call exportObject on an object that is already
    exported.

    2. Change the sentence in the description of toStub:

    The argument object must either be a subclass of PortableRemoteObject
    or have been previously the target of a call on
    PortableRemoteObject.exportObject.

    to the sentences:

    The argument object must currently be exported, either because it is
    a subclass of PortableRemoteObject or by virtue of a previous call
    to PortableRemoteObject.exportObject. If the object is not currently
    exported, a NoSuchObjectException is thrown.

    3. Change the sentence:

    The unexportObject method is used a deregister a server object from
    the ORB runtimes, allowing the object to become available for
    garbage collection.

    to the sentences:

    The unexportObject method is used a deregister a currently exported
    server object from the ORB runtimes, allowing the object to become
    available for garbage collection. If the object is not currently
    exported, a NoSuchObjectException is thrown.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

IDLEntity types need to be boxed

  • Key: JAV2I12-81
  • Legacy Issue Number: 2476
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When IDLEntity types are mapped from Java to IDL, they need to be
    mapped as valuetypes to preserve RMI null and sharing semantics.
    For most IDLEntity types, this will require the generation of
    boxed valuetypes in IDL, similarly to the mapping of Java arrays to
    IDL boxed sequences.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

Definition of Stub.equals method

  • Key: JAV2I12-80
  • Legacy Issue Number: 2475
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The definition of the equals method of javax.rmi.CORBA.Stub should
    say that this method returns false when used to compare stubs that
    do not represent the same remote object.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted (see summary for text)

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

Mapping for non-conforming class

  • Key: JAV2I12-79
  • Legacy Issue Number: 2474
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The mapping of a non-conforming class should be abstract valuetype,
    not valuetype. This is because instances of this type are not
    serializable, but instances of its subtypes are serializable.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted (see summary for text)

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

Mappings for non-conforming types

  • Key: JAV2I12-78
  • Legacy Issue Number: 2473
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The mapping for methods and constants in non-conforming types
    should be specified (by cross-reference to the words for value types).

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted (see summary for text)

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

Interfaces and values should be mapped consistently

  • Key: JAV2I12-77
  • Legacy Issue Number: 2472
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Java to IDL mapping rules for remote interfaces and value types
    should be consistent except where there is clear need for differences.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

RMI/IDL Tie changes

  • Key: JAV2I12-76
  • Legacy Issue Number: 2471
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following changes will improve the code generated for RMI/IDL Ties:

    a) RMI/IDL Tie classes shall catch org.omg.CORBA.SystemException and
    rethrow it (unwrapped by UnknownException).

    b) Change the signature of Util.mapSystemException to
    public static java.rmi.RemoteException
    mapSystemException(org.omg.CORBA.SystemException ex);

    c) RMI/IDL Tie classes shall throw the result from mapSystemException.

    d) mapSystemException shall return the mapped exception if it is an
    instance of RemoteException or a subclass, and shall throw the
    mapped exception in all other cases.

    This has been agreed by the RTF, but an OMG issue number is needed.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted (see summary for text)

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

Completion status missing from exception string

  • Key: JAV2I12-75
  • Legacy Issue Number: 2470
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The mapping of CORBA system exceptions to Java remote exceptions
    omits the completion status information. This should be preserved
    in the detail string.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

Change write_* names in Util class

  • Key: JAV2I12-72
  • Legacy Issue Number: 2467
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the javax.rmi.CORBA.Util class, the following names should be
    changed for consistency with the naming convention used in this package:
    write_RemoteObject to writeRemoteObject
    write_AbstractObject to writeAbstractObject
    This has been agreed by the RTF, but an OMG issue number is needed.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted (see summary for text)

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

IDLEntity exception types as parameters and results

  • Key: JAV2I12-74
  • Legacy Issue Number: 2469
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The specified Java to IDL mapping for IDLEntity exception types does
    not work for method parameters and results, because IDL exception
    types cannot be passed as method parameters and results.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted (see summary for text)

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

IIOP/JRMP stubs name clash

  • Key: JAV2I12-73
  • Legacy Issue Number: 2468
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The names of generated stub classes can be the same in some cases for
    IIOP and JRMP. This is a source of user error and confusion.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted (see summary for text)

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

Mangling of Java long type not specified

  • Key: JAV2I12-70
  • Legacy Issue Number: 2370
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The overloaded method name mangling for the Java long type is not
    specified in the spec. My suggestion is to use "long_long".

  • Reported: JAV2I 1.0 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted

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

Mapping private Java methods to IDL

  • Key: JAV2I12-71
  • Legacy Issue Number: 2466
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Java private methods and constructors should not be mapped to IDL.
    This has been agreed by the RTF, but an OMG issue number is needed.

  • Reported: JAV2I 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Closed, accepted (see summary for text)

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

Tie.deactivate() exception handling

  • Key: JAV2I12-15
  • Legacy Issue Number: 3152
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The javax.rmi.CORBA.Tie.deactivate() method does not declare any exceptions.
    However, when using a POA servant, the following exceptions can be thrown by
    the RMI/IDL tie's implementation of deactivate():

    org.omg.PortableServer.POAPackage.ServantNotActive
    org.omg.PortableServer.POAPackage.WrongPolicy
    (by the servant_to_id() method)

    org.omg.PortableServer.POAPackage.ObjectNotActive
    org.omg.PortableServer.POAPackage.WrongPolicy
    (by the deactivate_object() method)

    How should these exceptions be handled by Tie.deactivate()? If they should
    be rethrown by Tie.deactivate(), what exception(s) should be used?

    (This issue was raised by Max Mortazavi of Sun.)

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

    See revised text below.

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

Name mangling scheme broken.

  • Key: JAV2I12-13
  • Legacy Issue Number: 3117
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Say I have a class octet in the global scope and I have an interface

    interface foo extends java.rmi.Remote

    { void op(byte x); void op(octet y); }

    ;

    The operationsin IDL will now be

    op_octet (octet x) and op_octet(::_octet);

    which is incorrect.

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

    closed, no change

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

mapping from java.rmi Remote to CORBA::Object

  • Key: JAV2I12-12
  • Legacy Issue Number: 2111
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Are we trying to support sending JRMP stubs over IIOP? If so, then
    it would seem that the IDL mapping of java.rmi.Remote to CORBA::Object
    works against that; it would need to be changed to Any.

  • Reported: JAV2I 1.0b1 — Tue, 20 Oct 1998 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    See revised text below.

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

Mapping of CORBA any and TypeCode

  • Key: JAV2I12-24
  • Legacy Issue Number: 3969
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The Java to IDL mapping does not specify how the Java classes produced
    by the forward mapping from the CORBA "any" and "TypeCode" types should
    be mapped back to IDL.

    Since org.omg.CORBA.Any and org.omg.CORBA.TypeCode both inherit from
    IDLEntity, section 1.3.9 implies that these types should be "boxed" in
    the same way as other IDLEntity types. This would imply the following
    mapping to IDL:

    module org {
    module omg {
    module boxedIDL {
    module CORBA

    { valuetype _Any any; #pragma ID Any “RMI:org.omg.CORBA.Any:xxxxxxxxxxxxxxxx:yyyyyyyyyyyyyyyy” }

    ;
    };
    };
    };

    module org {
    module omg {
    module boxedIDL {
    module CORBA

    { valuetype TypeCode ::CORBA::TypeCode; #pragma ID TypeCode “RMI:org.omg.CORBA.TypeCode:xxxxxxxxxxxxxxxx:yyyyyyyyyyyyyyyy” }

    ;
    };
    };
    };

    The above raises a number of questions:

    1. What is the correct IDL name for the boxed valuetype enclosing the Java "Any"
    type? Is it ::org::omg::boxedIDL::CORBA::_Any or ::org::omg::boxedIDL::_any?

    2. How should the hashcodes and SUIDs be computed in the above repid pragmas?
    For other boxed IDLEntity Java types, these are computed from the actual
    implementation classes. However, for these two types, the actual
    implementation classes are ORB-specific and it seems meaningless to send
    their hashcodes or SUIDs on the wire. We could either do what we do for
    object references and send zeros for the hashcode and SUID, or we could
    use IDL-style repids instead or RMI-style repids for these types.

    3. Is it better to make these types an exception to the general rule as defined
    in section 1.3.9? An alternative non-boxed mapping would be to simply map
    them to the IDL/PIDL types "any" and "::CORBA::TypeCode". This would have
    the drawback that RMI semantics of being able to pass nulls and maintaining
    referential integrity for shared references to "by value" Java objects would
    not apply to these Java types.

  • Reported: JAV2I 1.0b1 — Wed, 18 Oct 2000 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    See revised text below.

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

Package for PortableRemoteObjectDelegate

  • Key: JAV2I12-23
  • Legacy Issue Number: 3858
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The Java to IDL mapping spec does not explictly specify the package for the
    PortableRemoteObjectDelegate interface.

    The correct fully-qualified name of this interface is
    javax.rmi.CORBA.PotableRemoteObjectDelegate. This is stated explictly in
    Harold Carr's final proposal for issue 2478, which contained the text:

    > The implementation delegate classes for PortableRemoteObject and Util must
    > implement the following new interfaces:
    >
    > javax.rmi.CORBA.PortableRemoteObjectDelegate (per-class delegation)
    > javax.rmi.CORBA.UtilDelegate (per-class delegation)

    and is also implied by the text that was voted on for issue 2478, which
    contained the following:

    > The implementation delegate classes for PortableRemoteObject and Util must
    > implement the following new interfaces for per-class delegation:
    >
    > package javax.rmi.CORBA;
    >
    > public interface UtilDelegate

    { > > .... > > }
    >
    > public interface PortableRemoteObjectDelegate { > > .... > > }

    The above code clearly makes both interfaces part of the javax.rmi.CORBA package.
    However, when these definitions were copied into the Java to IDL mapping spec,
    the interfaces UtilDelegate and PortableRemoteObject were placed in separate
    sections 1.5.3.2 and 1.5.3.3, and the package statement was copied to section
    1.5.3.2 but was unfortunately not copied to 1.5.3.3. This creates an ambiguity
    in the published spec document, since section 1.5.3.3 does not explicitly specify
    the package for PortableRemoteObjectDelegate.

    Proposed resolution:

    Add the line
    package javax.rmi.CORBA;
    to section 1.5.3.3.

  • Reported: JAV2I 1.0b1 — Tue, 5 Sep 2000 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    See revised text below

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

Descriptions of readAny and writeAny not precise enough

  • Key: JAV2I12-22
  • Legacy Issue Number: 3857
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The descriptions of readAny and writeAny in section 1.5.1.4 of the Java to IDL
    mapping spec are not very precise and don't say how null values should be handled.
    These methods are currently described in section 1.5.1.4 as follows:

    > The writeAny method writes the Java object obj to the output stream out in the
    > form of a GIOP any. The readAny method reads a GIOP any from the input stream
    > in and unmarshals it as a Java object, which is returned.

    Proposed resolution:

    Replace the above paragraph in section 1.5.1.4 by the following:

    The writeAny method writes the Java object obj to the output stream out in the
    form of a GIOP any. The contents of the GIOP any are determined by applying
    the Java to IDL mapping rules to the actual runtime type of obj. If obj is null,
    then it is written as follows: the TypeCode is tk_value, the repository ID is
    "IDL:omg.org/CORBA/ValueBase:1.0", the name string is "", the ValueModifier is
    VM_NONE, the concrete base is tk_null, the member count is 0, and the any's value
    is a null valuetype (0x00000000).

    The readAny method reads a GIOP any from the input stream in and unmarshals it
    as a Java object, which is returned. The following TypeCodes are valid for
    the GIOP any: tk_value, tk_value_box, and tk_objref. If the TypeCode is anything
    other than these, a MARSHAL exception is thrown.

  • Reported: JAV2I 1.0b1 — Tue, 5 Sep 2000 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    See revised text below.

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

ValueHandler Interface

  • Key: JAV2I12-21
  • Legacy Issue Number: 3798
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    In ptc/00-01-06.pdf, the ValueHandler Interface shows method
    implementations. According to Java conventions, the methods
    should not be implemented in interfaces. It is requested that
    this interface be updated to remove the method implementations.

  • Reported: JAV2I 1.0b1 — Thu, 31 Aug 2000 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    Remove method implementations from the definition of the ValueHandler interface.

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

Exception mapping needs fixing

  • Key: JAV2I12-19
  • Legacy Issue Number: 3670
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    When I have Java exceptions called

    foo
    fooException
    fooError

    they all get mapped to the exception fooEx causing collisions.

    I am not sure what the fix should be so I'll dump my thoughts here...

    The correct fix for this probably should be:

    foo -> fooEx
    fooException -> fooExcp
    fooError -> fooEr

    However, given that that would not be backward compatible, another solution
    would be

    All exceptions map to the Ex suffix. Each collision adds an _ (underscore) at
    the end, if there is a collision.

    However, this has problem with the name changing depending on which exception
    gets processed first, and the resultant definitions are not deterministic.

    Any other ideas?

  • Reported: JAV2I 1.0b1 — Thu, 1 Jun 2000 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    See revised text below

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

loader.loadClass() or Class.forName()?

  • Key: JAV2I12-17
  • Legacy Issue Number: 3590
  • Status: closed  
  • Source: Oracle ( Bob Scheifler)
  • Summary:

    In 1.4.9.5, #4 of the Java 2 case:

    4. If a class was not successfully loaded by step 1, 2, or 3, and loader is
    non-null, then call loader.loadClass(className)

    Shouldn't that really be Class.forName(className, false, loader), so that
    array types are handled properly?

    ClassLoader.loadClass does not handle creating new array types (it
    will only find previously created array types), Class.forName does.

  • Reported: JAV2I 1.0b1 — Tue, 2 May 2000 04:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    See revised text below.

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

No factory for javax.rmi.ClassDesc

  • Key: JAV2I12-16
  • Legacy Issue Number: 3433
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    There appears to be no way to construct a javax.rmi.ClassDesc, since the
    ClassDesc class has two private members and no constructor. This is required by
    non-default implementations of ValueHandler.

    There are many ways to solve this issue.
    1. Add a public constructor to javax.rmi.ClassDesc (preferred)
    2. Make members protected so other implementations can subclass and add
    constructors
    3. create a factory method in say Util that returns a ClassDesc which takes the
    required parameters.

  • Reported: JAV2I 1.0b1 — Mon, 20 Mar 2000 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    See revised text below

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

Mapping of Java byte constants to IDL

  • Key: JAV2I12-26
  • Legacy Issue Number: 4058
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Since Java byte values are mapped bit-for-bit to IDL (see section 1.3.3),
    the same should apply to byte constants. For example, -1 should map to 255.
    However, section 1.3.4.5 says that these constants are mapped to the
    same values.

    Proposed resolution:

    In section 1.3.4.5, change "are mapped to the same values" to "are mapped
    to the same values, except for byte constants which are mapped bit-for-bit.
    For example, -1 maps to 255."

  • Reported: JAV2I 1.0b1 — Thu, 16 Nov 2000 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    resolved, see below

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

Mapping CORBA minor codes to Java

  • Key: JAV2I12-25
  • Legacy Issue Number: 4004
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Section 1.4.8 of the Java to IDL mapping spec says that when mapping
    CORBA system exceptions to RMI exceptions, the minor code is formatted
    as a decimal number. This is a readability issue for both OMG standard
    minor codes and vendor-specific minor codes. For example, the OMG
    standard minor code 0x4f4d0001 would be formatted as 1330446337 and a
    vendor proprietary minor code 0xc9c25401 would be formatted as 3384955905
    (or -910011391 if using signed 32-bit arithmetic).

    Proposed resolution:

    In section 1.4.8, change the fourth bullet to:
    • followed by the hexadecimal value of the system exception’s minor code

    In the following paragraph, change the example detail string to:
    “CORBA UNKNOWN 0x31 Maybe”

  • Reported: JAV2I 1.0b1 — Mon, 30 Oct 2000 05:00 GMT
  • Disposition: Resolved — JAV2I 1.1
  • Disposition Summary:

    See revised text below.

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