Java to IDL Language Mapping Avatar
  1. OMG Specification

Java to IDL Language Mapping — All Issues

  • Acronym: JAV2I
  • Issues Count: 123
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
JAV2I14-2 No wire format defined for java.lang.reflect.Proxy classes JAV2I 1.2 open
JAV2I14-3 ORB shutdown should be configurable JAV2I 1.2 open
JAV2I14-1 Custom Marshaling Format Clarification JAV2I 1.2 open
JAV2I14-4 Guidance on RepositoryIDs for primitive types JAV2I 1.2 open
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-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
JAV2I13-17 Urgent issue: javax.rmi.CORBA.Stub serialVersionUID JAV2I 1.2 JAV2I 1.3 Resolved closed
JAV2I13-16 Stream encoding for omitted optional custom data JAV2I 1.2 JAV2I 1.3 Resolved closed
JAV2I12-99 Behavior of Java writeUTF/readUTF JAV2I 1.1 JAV2I 1.2 Resolved closed
JAV2I12-98 javax.rmi.CORBA.Util.isLocal RemoteException condition(s) not specified JAV2I 1.1 JAV2I 1.2 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-63 Specifying code downloading JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-62 Eliminating server wait code JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-68 RMI/ORB marshalling interface 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-66 Custom marshalling wire format 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-64 Mapping of RuntimeException JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-61 Mapping of Java arrays 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-58 Need overloaded write_Value method on OutputStream 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-56 Need to #include orb.id JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-55 JTS exceptions JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-69 javax.rmi package use JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-15 Tie.deactivate() exception handling JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-14 Stream format problem for custom marshalled RMI types JAV2I 1.0b1 JAV2I 1.2 Resolved closed
JAV2I13-12 Boolean attributes JAV2I 1.0b1 JAV2I 1.3 Resolved closed
JAV2I12-13 Name mangling scheme broken. JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I13-11 PortableRemoteObject.narrow(null) JAV2I 1.0b1 JAV2I 1.3 Resolved closed
JAV2I13-10 Mapping of Java constructors to init is broken JAV2I 1.0b1 JAV2I 1.3 Resolved closed
JAV2I13-14 Container/member name clashes JAV2I 1.0b1 JAV2I 1.3 Resolved closed
JAV2I13-13 Definition of serialVersionUID field JAV2I 1.0b1 JAV2I 1.3 Resolved closed
JAV2I14-11 Treatment of classes with writeReplace/readResolve methods JAV2I 1.0b1 JAV2I 1.4 Resolved closed
JAV2I12-12 mapping from java.rmi Remote to CORBA::Object JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-54 Local stubs proposal JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-53 read_AbstractObject and write_AbstractObject JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-52 Java to IDL identifier mapping JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-51 Should Portability APIs throw SystemException? 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-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-47 Should exportObject throw exceptions? 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-49 Omission in section 5.4.5 JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-48 Abstract Interfaces issue 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-44 mangling rule for name clashes in IDL needs to be defined 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-36 Need to emit ID pragmas after declarations 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-40 Can toStub take a stub? JAV2I 1.0b1 JAV2I 1.0 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-20 Java reverse mapping local case cannot properly support Portable Intercepto JAV2I 1.0b1 JAV2I 1.2 Resolved closed
JAV2I12-19 Exception mapping needs fixing JAV2I 1.0b1 JAV2I 1.1 Resolved closed
JAV2I12-18 Java to IDL mapping contradictive to CORBA/IIOP 2.3.1 JAV2I 1.0b1 JAV2I 1.2 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-35 Mapping for nested sequences --- fix example JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-34 Unicode example needs fixing JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I12-33 SerializationInputStream and SerializationOutputStream JAV2I 1.0b1 JAV2I 1.0 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
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-32 Obtaining a default ORB 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-27 Public method declarations in ResponseHandler interface JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I13-15 Support for serialPersistentFields JAV2I 1.0b1 JAV2I 1.3 Resolved closed
JAV2I12-28 orb() method on InputStream JAV2I 1.0b1 JAV2I 1.0 Resolved closed
JAV2I14-10 Section: 1.3, Page: 1-21 JAV2I 1.3 JAV2I 1.4 Resolved closed
JAV2I14-9 Mapping CORBA activity exceptions to Java JAV2I 1.3 JAV2I 1.4 Resolved closed
JAV2I14-8 defaultWriteObject clarification JAV2I 1.3 JAV2I 1.4 Resolved closed
JAV2I14-7 Custom marshalled abstract interfaces and Java/IDL JAV2I 1.3 JAV2I 1.4 Resolved closed
JAV2I13-9 Name mapping rules for non-ASCII characters JAV2I 1.2 JAV2I 1.3 Resolved closed
JAV2I14-6 Custom marshalled abstract interfaces and Java/IDL JAV2I 1.3 JAV2I 1.4 Resolved closed
JAV2I14-5 Request clarification on copyObject(s) semantics JAV2I 1.3 JAV2I 1.4 Resolved closed
JAV2I13-6 Issue with ValueHandler.getRunTimeCodeBase and PRO.exportObject JAV2I 1.2 JAV2I 1.3 Resolved closed
JAV2I13-5 Java Codebase tagged component and POA JAV2I 1.2 JAV2I 1.3 Resolved closed
JAV2I13-8 scheme for mapping names is pretty byzantine JAV2I 1.2 JAV2I 1.3 Resolved closed
JAV2I13-7 1.2.3 RMI/IDL Remote Interfaces 2 JAV2I 1.2 JAV2I 1.3 Resolved closed
JAV2I12-8 Mapping of ExceptionDetailMessage service context JAV2I 1.1 JAV2I 1.2 Resolved closed
JAV2I12-7 New issue: Behavior of writeByte, writeChar, writeBytes, writeChars JAV2I 1.1 JAV2I 1.2 Resolved closed
JAV2I12-6 Mapping subclasses of custom-marshaled Java classes to IDL JAV2I 1.1 JAV2I 1.2 Resolved closed
JAV2I12-5 Issue with using the local stub with for example an EJB application JAV2I 1.1 JAV2I 1.2 Resolved closed
JAV2I12-11 RMI-IIOP interop bet. J2SE 1.3 and 1.4 JAV2I 1.1 JAV2I 1.2 Resolved closed
JAV2I12-10 mapSystemException server mapping JAV2I 1.1 JAV2I 1.2 Resolved closed
JAV2I12-9 There is a typo on page 1-46. JAV2I 1.1 JAV2I 1.2 Resolved closed

Issues Descriptions

No wire format defined for java.lang.reflect.Proxy classes

  • Key: JAV2I14-2
  • Legacy Issue Number: 7595
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    Java serialization supports the serialization of proxy classes explicitly. It does this by essentially marshaling into the stream the list of interfaces that the proxy implements and on the other end calling Proxy.getProxyClass() with those interfaces. In RMI-IIOP the proxy class ends up coming across the wire with a repository ID of RMI:\U0024Proxy0:2D4A76C198E9D8DA:0000000000000000 (i.e. $Proxy) which is not a real class and cannot be loaded by the client.

    I think we probably need to mandate specific behaviour for proxy classes along the lines of the java serialization spec. A simple approach might be to mandate that the valuetype contain a list of repids, the first being the pseudo-repid for the proxy itself and the other being the repids of the interfaces the proxy supports. The actual data would be that of the proxy itself which is basically the InvocationHandler.

  • Reported: JAV2I 1.2 — Tue, 20 Jul 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

ORB shutdown should be configurable

  • Key: JAV2I14-3
  • Legacy Issue Number: 5853
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    Section 1.6.1 states:

    "A call to exportObject with no objects exported creates a non-daemon thread that
    keeps the Java virtual machine alive until all exported objects have been unexported by
    calling unexportObject."

    However, there is no implicit way to unexport objects and so this places the burden on the users to do so. It may be that users are not exporting objects themselves but using some layered product that does so - in this case they would have to call a shutdown API in order for their program to exit. All of these solutions are non-intuitive and not helpful to the user who forgets to call the requied API - their program just does not exit.

    I would like to suggest that this behavior be configurable in some way, either via exportObject or via properties so that users and implementors can choose whether or not a particular exported object should cause the VM to stay alive.

  • Reported: JAV2I 1.2 — Fri, 7 Feb 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Custom Marshaling Format Clarification

  • Key: JAV2I14-1
  • Legacy Issue Number: 5879
  • Status: open  
  • Source: Anonymous
  • Summary:

    Consider the following Java classes:

    public class A implements java.io.Serializable

    { // This is a non custom class // A's data -- omitted // A's constructors - omitted // A's methods -- omitted }

    public class B extends A {
    // B's data – omitted here
    // B's cobstructors – omitted here

    // This is a custom class
    private void writeObject(java.io.ObjectOutputStream s)

    { .... }

    // Other methods omitted
    }

    public class C extends B { // This is a non-custom class // C's data -- omitted // C's constructors - omitted // C's methods -- omitted }

    public class D extends C {
    // D's data – omitted here
    // D's cobstructors – omitted here

    // This is a custom class
    private void writeObject(java.io.ObjectOutputStream s) { .... }

    // Other methods omitted
    }

    Here we have a class inheritance hierarchy as D:C:B:A with A and C as non-custom classes, B and D as custom classes. What is the rmi-iiop data layout on the wire when an instance of D is marshaled in terms of customer header and data w.r.t. to each of the super classes? Which one of the following layout is correct?

    -----------------------------------------------------------------------------------------
    a. | A-Data | B-FV B-DWO B-Data | CData | FV-D DWO-D DData |
    -----------------------------------------------------------------------------------------

    --------------------------------------------------------------------------------------------------------------------------------
    b. | A-FV A-DWO A-Data | B-FV B-DWO B-Data | C-FV C-DWO C-Data | D-FV D- DWO DData |
    -------------------------------------------------------------------------------------------------------------------------------

    ----------------------------------------------------------------------------
    c. | A-FV A-DWO A-Data | B-Data | C-Data | DData |
    ---------------------------------------------------------------------------

    Terms used for illustration purpose here:

    A-FV ------ means the Format version octet for class A
    A-DWO ------ means the defaultWriteObject boolean flag for class A
    A-Data ----- means the data fields of class A.

    B-FV ------ means the Format version octet for class B
    B-DWO ------ means the defaultWriteObject boolean flag for class B
    B-Data ----- means the data fields of class B

    C-FV ------ means the Format version octet for class C
    C-DWO ------ means the defaultWriteObject boolean flag for class C
    C-Data ----- means the data fields of class C.

    D-FV ------ means the Format version octet for class D
    D-DWO ------ means the defaultWriteObject boolean flag for class D
    D-Data ----- means the data fields of class D.

  • Reported: JAV2I 1.2 — Fri, 7 Mar 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Guidance on RepositoryIDs for primitive types

  • Key: JAV2I14-4
  • Legacy Issue Number: 5891
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    I have noticed that the Sun ORB generates RepositoryIds for primitive types when generating a FullValueDescription that looks like this:

    RMI:int:000000000000000000

    Now you could argue that the type of int is Integer.TYPE and the function getName() on this class does indeed return "int" however there are explicit mappings for primitive types (int -> IDL long) and this just seems wrong to me.

    Should the repid be null or something else? Does it matter?

  • Reported: JAV2I 1.2 — Tue, 18 Mar 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

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

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

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

Behavior of Java writeUTF/readUTF

  • Key: JAV2I12-99
  • Legacy Issue Number: 4319
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    Java Serializable classes can define their own readObject/writeObject
    methods which take java.io.ObjectInputStream and
    java.io.ObjectOutputStream parameters, respectively.

    What is the proper behavior of the readUTF and writeUTF methods on these
    streams in RMI-IIOP? The Java to IDL specification doesn't mention
    these methods.

    Proposed resolution:

    In RMI-IIOP, java.io.ObjectOutputStream's writeUTF method should write a
    CORBA wstring. Similarly, readUTF should read a CORBA wstring.

    Discussion:

    One must override these methods to avoid using the internal java.io
    implementations. Looking at the JDK 1.3 code, the behavior is specific
    to Java serialization. If one doesn't override writeUTF and readUTF,
    Java serialization mechanisms such as blocks (similar to chunks) may be
    introduced on the wire in RMI-IIOP.

  • Reported: JAV2I 1.1 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    See revised text below

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

javax.rmi.CORBA.Util.isLocal RemoteException condition(s) not specified

  • Key: JAV2I12-98
  • Legacy Issue Number: 4296
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The Java to IDL spec
    (http://cgi.omg.org/cgi-bin/doc?ptc/00-01-06, section 1.5.1.4 page 47)
    says:

    "The isLocal method has the same semantics as the ObjectImpl._is_local
    method, except that it can throw a RemoteException."

    However, it does not specify under what conditions a remote exception
    is thrown.

    Either the exception condition(s) should be specified or the exception
    should be removed from the signature.

  • Reported: JAV2I 1.1 — Tue, 8 May 2001 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    See revised text below

  • Updated: Fri, 6 Mar 2015 21:38 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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

Stream format problem for custom marshalled RMI types

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

    There is a problem in the stream format for custom marshalled RMI types.
    The Java serialization spec requires that when a class with a writeObject
    method calls defaultWriteObject and then writes optional data, the receiver
    must be able to skip the optional data if the readObject does not consume
    it or the class is not in the receiver's hierarchy. So if the sender's
    hierarchy consists of serializable classes Base and Derived, both of which
    call defaultWriteObject and then write optional data, there must be a way
    for the unmarshaller to first skip to the end of the Base data, then skip
    to the end of the Derived data. With the current stream format, this is
    not possible.

  • Reported: JAV2I 1.0b1 — Mon, 20 Dec 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    see below

  • 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

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

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

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

Treatment of classes with writeReplace/readResolve methods

  • Key: JAV2I14-11
  • Legacy Issue Number: 2552
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We should consider whether a Java class that has a writeReplace or a
    readResolve method (with the appropriate signature for use by object
    serialization) should map to a custom valuetype in IDL instead of
    a normal valuetype. We should also think harder about the impact
    of writeReplace/readResolve semantics on non-Java ORBs: can non-Java
    implementations properly receive and send instances of such classes,
    maintaining all the proper sharing, without running into type checking
    problems, and without any additions to non-Java ORBs?

  • Reported: JAV2I 1.0b1 — Fri, 19 Mar 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

  • 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Java reverse mapping local case cannot properly support Portable Intercepto

  • Key: JAV2I12-20
  • Legacy Issue Number: 3754
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The local mapping makes it impossible to determine which ending point
    to call.

    ptc/00-01-06 says:

    BEGIN_QUOTE

    1.5.2.2 Local Stubs

    The stub class may provide an optimized call path for local server
    implementation objects. For a method echo(int x) of a remote interface
    Aardvark, the optimized path does the following:

    1. Find out if the servant is local by calling Util.isLocal()
    2. If the servant is local, call
    this._servant_preinvoke("echo",Aardvark.class)
    3. If _servant_preinvoke returned a non-null ServantObject so, call
    ((Aardvark)so.servant).echo
    4. If _servant_preinvoke returned a non-null ServantObject so, call
    this._servant_postinvoke(so)
    5. If _servant_preinvoke returned null, repeat step 1. The call to
    Util.isLocal() will return false, causing the non-optimized
    path to be followed.
    ...

    The following is an example of a stub class that provides this
    optimized call path.

    // Java
    public class _Aardvark_Stub extends javax.rmi.CORBA.Stub
    implements Aardvark
    {
    public int echo(int x)
    throws java.rmi.RemoteException, Boomerang
    {
    if (!javax.rmi.CORBA.Util.isLocal(this))

    { ... }

    else {
    // local call path
    org.omg.CORBA.portable.ServantObject so =
    _servant_preinvoke("echo", Aardvark.class);
    if (so == null)
    return echo;
    try

    { return ((Aardvark)so.servant).echo(x); }

    catch (Throwable ex)

    { Throwable ex2 = (Throwable) javax.rmi.CORBA.Util.copyObject(ex, _orb()); if (ex2 instanceof Boomerang) throw (Boomerang)ex2; else throw javax.CORBA.Util.wrapException(ex2); }

    finally

    { _servant_postinvoke(so); }

    }
    }
    }

    END_QUOTE

    ClientRequestInterceptor::send_request would need to be invoked by the
    ORB inside _servant_preinvoke.

    ClientRequestInterceptor::receive_reply or receive_exception would
    need to be called inside _servant_postinvoke.

    (Note that receive_other would not happen since, if a POA were
    involved inside _servant_preinvoke and a servant manager raised
    ForwardRequest, this should cause _servant_preinvoke to return null
    resulting in a recursive call to the method. In this case the ORB
    would not call send_request in the first place, or, if it did, it
    would handle the call to the receive_other internally inside of
    _servant_preinvoke.)

    One is tempted to say that the ORB could remember if
    javax.rmi.CORBA.Util.copyObject was called on behalf of this request.
    In that case, when _servant_postinvoke is called it would know there
    was an exception (and would have it hands on the exception object -
    which needs to be available via Portable Interceptors).

    However, this does not work. The example does not show it, but if the
    method returns values those values are filtered through
    javax.rmi.CORBA.Util.copyObject before being returned to the client.
    Exception objects are legal return values. So there is no way to
    determine if copyObject was called to copy return values or exception
    objects resulting from an actually exception. Therefore this trick
    will not work.

    Bottom line: there is no reliable way to determine which Portable
    Interceptor ending point to call in the Java reverse mapping local
    case.

  • Reported: JAV2I 1.0b1 — Fri, 21 Jul 2000 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    see below

  • 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

Java to IDL mapping contradictive to CORBA/IIOP 2.3.1

  • Key: JAV2I12-18
  • Legacy Issue Number: 3641
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The Java to IDL Language Mapping (formal/99-07-59) seems to contradict the CORBA/IIOP 2.3.1 Specification (formal/99-10-07) over exceptions being raised by valuetype initialisers.

    Section 1.3.5.4 of 99-07-59, point 3 states that exceptions thrown by a constructor of an object-by-value class are mapped to the corresponding OMG IDL exception.

    On the other hand, section 2.8.1.5 of 99-10-07 does not allow initialisers to include a raises clause (contrast this with the syntax for an operation declaration in section 3.12).

    This is a significant inter-operability problem. In my case the IDL generated by the IBM/SUN RMI-IIOP Java-to-IDL compiler (which includes 'raises' clauses in valuetype initialisers) is rejected as syntactically invalid by the MICO IDL-to-C++ compiler.
    submit: Submit Issue Report

  • Reported: JAV2I 1.0b1 — Wed, 24 May 2000 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    Close, no change. Core RTF issue 4785 has added exceptions to IDL valuetype initializers, which reso

  • 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 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

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

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

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

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

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

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

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

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

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

Section: 1.3, Page: 1-21

  • Key: JAV2I14-10
  • Legacy Issue Number: 10336
  • Status: closed  
  • Source: Borland ( Naveed Shaikh)
  • Summary:

    Java to IDL Language Mapping Specification doesn't cover the mapping for Java enum from JDK 1.5. We propose the following mapping to be included in the specification. Mapping for Enumeration: When used as a parameter, return type or member variable, Java enum in JDK 1.5 is mapped to the OMG IDL type ::javax::rmi::CORBA::EnumDesc. The corresponding representation in Java class is: package javax.rmi.CORBA; public class EnumDesc implements java.io.Serializable

    { // Holds the value of enum public String value; // Name of enum class public String className; static final long serialVersionUID = ...; }

    The mapping in IDL will be: module javax { module rmi { module CORBA { valuetype EnumDesc

    { public ::CORBA::WStringValue value; #pragma ID value "RMI:EnumDesc/value:xxxxx" public ::CORBA::WStringValue className; #pragma ID className "RMI:EnumDesc/className:xxxxx" }

    ; #pragma ID EnumDesc "RMI:EnumDesc:aaaaaa:xxxxxxxxx" }; }; };

  • Reported: JAV2I 1.3 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

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

Mapping CORBA activity exceptions to Java

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

    The CORBA activity specification (Additional Structuring Mechanisms for
    the OTS, v1.0, OMG document formal/02-09-03) introduced three new system
    exceptions (INVALID_ACTIVITY, ACTIVITY_COMPLETED, and ACTIVITY_REQUIRED)
    that were incorporated into CORBA 3.0.

    The JCP J2EE Activity Service for Extended Transactions (JSR 95) adds
    three equivalent exceptions
    javax.activity.InvalidActivityException
    javax.activity.ActivityCompletedException
    javax.activity.ActivityRequiredException
    to the Java platform.

    The Java to IDL mapping should be extended to map these CORBA exceptions
    to the equivalent Java activity exceptions, just as the three CORBA
    transaction system exceptions are currently mapped to the equivalent
    JTA exceptions in the javax.transaction package.

    Proposal:

    In section 1.4.8, add the following rows to table 1-2:

    CORBA Exception RMI Exception
    --------------- -------------
    INVALID_ACTIVITY javax.activity.InvalidActivityException
    ACTIVITY_COMPLETED javax.activity.ActivityCompletedException
    ACTIVITY_REQUIRED javax.activity.ActivityRequiredException

  • Reported: JAV2I 1.3 — Fri, 2 Apr 2004 05:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

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

defaultWriteObject clarification

  • Key: JAV2I14-8
  • Legacy Issue Number: 6992
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    We have recently found an interop problem with another Vendor's orb and wanted some clarification on the customer marshaling format wrt defaultWriteObject. 1.4.10 says:

    For serializable objects with a writeObject method:
    b. boolean - True if defaultWriteObject was called, false otherwise.

    However it is mute on the subject of writeFields and readFields. The Java serialization spec indicates that defaultWriteObject and writeFields are somewhat equivalent, so (a) one could argue that the boolean should be true if writeFields has been called. (b) One could also argue that the spec doesn't say this and so the boolean should be false. My feeling is that (a) is correct (and this is what the other orb does) but that it should be called out explicitly in the spec.

    Comments appreciated

  • Reported: JAV2I 1.3 — Tue, 17 Feb 2004 05:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

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

Custom marshalled abstract interfaces and Java/IDL

  • Key: JAV2I14-7
  • Legacy Issue Number: 6411
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    We currently are having a problem implementing abstract interface behaviour in C++ for valuetypes marshaled according to the Java/IDL spec. For custom marshaled objects the spec says:

    "Other Java objects are marshaled in the form of an
    IDL abstract interface (i.e., a union with a boolean discriminator containing either an
    object reference if the discriminator is true or a value type if the discriminator is false)."

    However, the Java/IDL spec does not mandate that all Java objects of this type be mapped to IDL that has an abstract interface as a supertype. Thus we are left in the position for IDL that objects marshaled as abstract interfaces are not truly abstract interfaces as defined in the CORBA spec section 6.2. Moreover the generated C++ for these types will not include inheritance from AbstractBase, so how should these types be handled? In particular should DataInputStream::read_Abstract() work at all for these types? You could imagine making this work by having read_Abstract() return some container class that held the actual object (valuetype or object reference), but its not clear that this is actual legal wrt 6.2.

    Clarification appreciated

  • Reported: JAV2I 1.3 — Mon, 3 Nov 2003 05:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • 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

Custom marshalled abstract interfaces and Java/IDL

  • Key: JAV2I14-6
  • Legacy Issue Number: 6410
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    We currently are having a problem implementing abstract interface behaviour in C++ for valuetypes marshaled according to the Java/IDL spec. For custom marshaled objects the spec says:

    "Other Java objects are marshaled in the form of an
    IDL abstract interface (i.e., a union with a boolean discriminator containing either an
    object reference if the discriminator is true or a value type if the discriminator is false)."

    However, the Java/IDL spec does not mandate that all Java objects of this type be mapped to IDL that has an abstract interface as a supertype. Thus we are left in the position for IDL that objects marshaled as abstract interfaces are not truly abstract interfaces as defined in the CORBA spec section 6.2. Moreover the generated C++ for these types will not include inheritance from AbstractBase, so how should these types be handled? In particular should DataInputStream::read_Abstract() work at all for these types? You could imagine making this work by having read_Abstract() return some container class that held the actual object (valuetype or object reference), but its not clear that this is actual legal wrt 6.2.

    Clarification appreciated.

  • Reported: JAV2I 1.3 — Mon, 3 Nov 2003 05:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

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

Request clarification on copyObject(s) semantics

  • Key: JAV2I14-5
  • Legacy Issue Number: 5991
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    Questions have come up recently about copyObject behavior, both within Sun and from customers.
    The main question is whether it is necessary to actually copy immutable objects, or can copyObject( obj )
    simply return obj for immutable objects. The standard immutable
    objects in question are String and the primitive type wrappers (Integer etc.).

    Looking at ptc/02-01-12, the main part of the specification that is relevant is section 1.5.1.6,
    on the bottom of page 1-52. The statement is made here that "(copyObject and copyObjects) observe
    copy semantics for value objects that are equivalent to marshalling, ...". What exactly does
    equivalent mean here?

    It seems to me that the most important property here is that any sequence of method invocations
    made by the "client" do not affect the results of any sequence of method invocations made by
    the "server" (or vice-versa). This is normally the case for immutable objects that are copied by reference.
    However, locking of an object passed by reference is possibly observable. Normally, the
    "client" and the "server" in the colocated case are actually running on the same thread, but
    each role could pass object obj and copyObject(obj) to a different thread. Different results
    are then possible for the copy/non-copy case, depending on the locking behavior of the threads.

    There are old parts of the rmic -iiop code and the Sun ORB, dating from the days when Sun and IBM
    were jointly developing RMI-IIOP, that show evidence of both possible interpretations. For
    example, StubGenerator.mustCopy( TYPE_STRING ) returns false, so that a method that takes
    only one or more String arguments would not have a call to copyObject(s) generated in the stub.
    However, the implementation of Util.copyObject(s) always copies String instances.

    I would like to see the text clarified in the specification to explicitly state whether immutable
    objects need to be copied or not.

  • Reported: JAV2I 1.3 — Mon, 7 Jul 2003 04:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

  • 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

scheme for mapping names is pretty byzantine

  • Key: JAV2I13-8
  • Legacy Issue Number: 5742
  • Status: closed  
  • Source: Boeing ( Mr. 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 ( Mr. 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

Mapping of ExceptionDetailMessage service context

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

    The interop RTF resolved issue 3405 by adding a new service context called
    ExceptionDetailMessage. The usage of this service context was left to
    language mappings to define. This usage has been defined for the IDL to Java
    mapping (issue 4013) but not for the Java to IDL mapping.

    The resolution for issue 4013 defines how this service context shall be used
    when marshaling and unmarshaling system exceptions. However, an RMI-IIOP client
    never receives a system exception, but instead receives a mapped RemoteException
    or RuntimeException that was created by applying the rules specified in
    section 1.4.8. Currently these rules do not take account of any detail message
    that the system exception has acquired from the ExceptionDetailMessage service
    context by applying the mappings specified by the resolution of issue 4013.

    In order to ensure that this valuable diagnostic information is available on
    exceptions received by RMI-IIOP clients as well as IDL clients, I propose the
    following change to section 1.4.8 of the Java to IDL mapping spec.

    Proposed resolution:

    After table 1-2, replace

    "In all cases, ..."

    by

    "If the getMessage() method of the CORBA system exception returns a non-null
    and non-empty string, the RMI exception is created with this string as its
    detail string. In all other cases, ..."

  • Reported: JAV2I 1.1 — Thu, 1 Nov 2001 05:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    see above

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

New issue: Behavior of writeByte, writeChar, writeBytes, writeChars


Mapping subclasses of custom-marshaled Java classes to IDL

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

    The Java to IDL mapping spec says that serializable Java classes that
    have a writeObject method are mapped to IDL custom valuetypes. This
    should also apply to any Java subclasses of these classes, since otherwise
    the generated IDL is illegal. (An IDL non-custom valuetype can't
    inherit from an IDL custom valuetype.)

    Proposed resolution:

    In section 1.3.5.6 of the Java to IDL mapping spec, change the first sentence
    of the second paragraph from

    If the class does not implement java.io.Externalizable but does have a
    writeObject method, ...

    to:

    If the class does not implement java.io.Externalizable but does have a
    writeObject method, or extends such a class directly or indirectly, ...

  • Reported: JAV2I 1.1 — Wed, 15 Aug 2001 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    Closed, accepted. See revised text below

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

Issue with using the local stub with for example an EJB application

  • Key: JAV2I12-5
  • Legacy Issue Number: 4429
  • Status: closed  
  • Source: Anonymous
  • Summary:

    When using the local stub with for example an EJB application, we discovered the following critical issue.

    Let's take an simple example :

    public interface HelloWorld extends javax.rmi.EJBObject

    { void print( String message ); }

    The generated Stub according to the mapping rules contains the methods for the inherited interface as for example 'getEJBHome'.

    For a local invocation on 'getEJBHome' the following part of the stub will be used :

    public javax.ejb.EJBHome getEJBHome() throws java.rmi.RemoteException { while( true ) { if (!javax.rmi.CORBA.Util.isLocal(this) )

    { // non local use }

    else { org.omg.CORBA.portable.ServantObject _so = _servant_preinvoke("EJBHome", HelloWorld.class);

    if ( _so == null ) return getEJBHome();

    try

    {return ((javax.ejb.EJBObject)_so.servant).getEJBHome(); }

    catch ( Throwable ex )

    { Throwable ex2 = ( Throwable ) javax.rmi.CORBA.Util.copyObject(ex, _orb()); throw javax.rmi.CORBA.Util.wrapException(ex2); }

    finally {_servant_postinvoke(_so); } } } }

    The '_servant_preinvoke' method will return a servant class of type 'HelloWorld' that implements the 'getEJBHome' operation.

    Thus, the '_HelloWorld_Tie' servant is returned.

    Then, the cast to convert the returned servant to 'javax.ejb.EJBObject' will fail since the servant doesn't implement this interface ( it only inherits from org.omg.PortableServer.Servant and implements javax.rmi.CORBA.Tie ).

    Thus, by using the local stub, it is not possible to invoke an inherited operation.

    Solution :

    The returned servant is always implementing 'javax.rmi.CORBA.Tie'. To allow the correct cast to 'javax.ejb.EJBObject' we need to access the final target instead of the servant itself. So the following solution can be always applied :

    javax.rmi.CORBA.Tie tie = ((javax.rmi.CORBA.Tie)_so.servant);

    return ((javax.ejb.EJBObject)tie.getTarget()).getEJBHome();

  • Reported: JAV2I 1.1 — Wed, 25 Jul 2001 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    Closed, accepted. See revised text below.

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

RMI-IIOP interop bet. J2SE 1.3 and 1.4

  • Key: JAV2I12-11
  • Legacy Issue Number: 4795
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

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

    RuntimeExceptions/Errors are broken in RMI-IIOP when interoperating
    between J2SE 1.3 and 1.4 (or "class evolution in service contexts is
    broken").

    When an unchecked exception (RuntimeException, Error) occurs in
    RMI-IIOP, it is translated into a CORBA UNKNOWN system exception, and
    the real Java exception is marshaled as a CDR encapsulation in the
    UnknownExceptionInfo service context. (Java to IDL formal 01-06-07
    1.4.7, 1.4.8.1)

    In J2SE 1.4, java.lang.Throwable has evolved to add several new
    non-transient fields including

    private Throwable cause;
    private StackTraceElement[] stackTrace;

    This means that when J2SE 1.3.x talks to 1.4 and an unchecked
    exception occurs, there is a class evolution scenario occurring inside
    of the UnknownExceptionInfo service context. Normally, class
    evolution is handled by using the SendingContextRunTime CodeBase to
    find out what the sender put on the wire. This service context is
    sent by the client on the first request on a connection and by the
    server on the first reply on a connection. (Java to IDL formal
    01-06-07 1.5.1)

    This presents two problems:

    1. Since the UnknownExceptionInfo service context has the Throwable
    in an encapsulation, technically it has no connection information.

    2. Even if we assumed that we use the connection on which this
    encapsulation is transmitted, we would need to make sure that the
    SendingContextRunTime service context is unmarshaled BEFORE the
    UnknownExceptionInfo service context so that the connection has the
    CodeBase to use to unmarshal the evolved Throwable class.

    Here are two possible solutions:

    1. Service context ordering proposal (strawman):

    Require that service context encapsulations use the connection on
    which they are sent if they need the CodeBase, and that the
    UnknownExceptionInfo service context must be unmarshaled after the
    SendingContextRunTime service context. Specifically, add this
    language to the Java to IDL spec in section 1.4.8.1.

    Note: We may need to be careful not to generalize to all service
    contexts. For instance, code sets for wstring/wchar inside of service
    context encapsulations should probably be explicitly stated when
    defining the service context at the spec level.

    2. New service context & backwards compatibility proposal:

    Add a new UnknownExceptionInfo service context called something like
    UnknownExceptionInfoPlusCodeBase service context. It contains the
    CodeBase IOR followed by the java.lang.Throwable. Thus, all necessary
    information is contained, and we can support evolution going forward
    in this particular service context. Older receivers would just
    disregard it.

    For backwards compatibility with J2SE 1.3 and before, we must still
    also send the original UnknownExceptionInfo service context containing
    something that looks like the J2SE 1.3 java.lang.Throwable class.
    Thus, we must define the format of this new structure and how to
    translate from J2SE 1.4 or later Throwables to it.

  • Reported: JAV2I 1.1 — Wed, 19 Dec 2001 05:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    see below

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

mapSystemException server mapping

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

    Ie RemoteException and subclasses are not RMI/IDL Exception types. (Note
    > > >however,
    > > >that the section refered to doesn't explicitly state that. That is a spec
    > > >problem). The spec provides these options:
    > > >If the CORBA system exception org.omg.CORBA.portable.UnknownException
    > > >is thrown, then the stub does one of the following:
    > > >- Translates it to org.omg.CORBA.UNKNOWN.
    > > >- Translates it to the nested exception that the UnknownException contains.
    > > >- Passes it on directly to the user.
    > > >
    > > >This option is needed because, some userdefined runtime exception, say,
    > > >may not
    > > >have an equivalent implementation on the receiving end. If we fix remote
    > > >exception to always result in the "right" exception on the wire, this case
    > > >occurs
    > > >only when there is an unexpected exception (such as a null pointer), which
    > > >should
    > > >be OK. The intent here was to talk about base classes and not individual types, but I
    > > >agree this is not explicit. Ideally, only remote exceptions that don't
    > > >have the
    > > >explicit reverse (rmi-to-system) mapping should result in a ServerException.
    > >
    > > Right, your first point makes this not so bothersome.
    > >
    > > > > >2. What about C++ clients ? The server should have converted any Java
    > > > > >Exception into a CORBA SYSTEM/USER exception where this is possible,
    > > > so that
    > > > > >any non-Java clients can deal with the Exceptions. Especially for the
    > > > > >TRANSACTION exceptions where a one-to-one mapping is possible, so that C++
    > > > > >clients know about those events from an RMI-IIOP server. Unfortunately the
    > > > > >Table 1-2, CORBA and RMI Exceptions (p. 1-33), has no one-to-one
    > > > mapping, so
    > > > > >Then mapping into the other direction some information will get lost.
    > > > >
    > > > > The problem is actually worse than this. If the server throws an exception
    > > > > that is a subclass of a declared exception, the client will get the Java
    > > > > IDL mapped exception (e.g. FooException -> FooEx) but
    > > > > there_is_no_way_for_the_client_to_handle_it because the IDL does not
    > > > > declare FooEx - and IDL does not allow exception inheritance. I would like
    > > > > to propose therefore that in the "standard" exception mapping that only
    > > > > exceptions of the declared type are thrown and that any exception
    > > > > inheritance is represented in the detail which is the actual java
    > > > > exception. We are actually doing this already in our server because it is
    > > > > the only reasonable way to make C++ clients work with EJBs.

  • Reported: JAV2I 1.1 — Sun, 11 Nov 2001 05:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    Closed, accepted. See revised text below

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

There is a typo on page 1-46.

  • Key: JAV2I12-9
  • Legacy Issue Number: 4690
  • Status: closed  
  • Source: Anonymous
  • Summary:

    "The mapSystemException method maps a CORBA system exception to a java.rmi.RemoteException or a java.rmi.RuntimeException."

    There is no java.rmi.RuntimeException, instead it should read: java.lang.RuntimeException !

  • Reported: JAV2I 1.1 — Thu, 8 Nov 2001 05:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    Closed, accepted. See revised text below

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