Issues for Java to IDL RTF Discussion Mailing List

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1578: Public method declarations in ResponseHandler interface
Issue 1589: orb() method on InputStream
Issue 1590: Marshalling of Any, Context, Principal, and TypeCode
Issue 1591: Default Constructor for Stubs
Issue 1592: How to make IDLEntity types serializable
Issue 1593: Obtaining a default ORB
Issue 1594: SerializationInputStream and SerializationOutputStream
Issue 1595: Unicode example needs fixing
Issue 1596: Mapping for nested sequences --- fix example
Issue 1597: Need to emit ID pragmas after declarations
Issue 1598: Lexigraphic sort for field names is before mangling
Issue 1599: Narrow signature does not allow use for abstract interfaces
Issue 1600: Section 5.7.4 : mapped IDL issue
Issue 1601: Can toStub take a stub?
Issue 1602: Does toStub return most derived stub?
Issue 1603: Clarify rules for mapping server-side errors and exceptions
Issue 1604: The generated IDL in A2 needs to be changed
Issue 1606: mangling rule for name clashes in IDL needs to be defined
Issue 1607: Do we need to protect non-generated IDL files against multiple inclusion?
Issue 1608: Rules in section 7.4.4 for toStub IIOP/JRMP search not correct
Issue 1609: Should exportObject throw exceptions?
Issue 1610: PortableRemoteObject toStub should throw NoSuchObject Exception
Issue 1619: Abstract Interfaces issue
Issue 1620: Omission in section 5.4.5
Issue 1621: Stub methods for hashCode, equals and toString
Issue 1640: Should Portability APIs throw SystemException?
Issue 1641: Mapping of Java names that are IDL keywords
Issue 1642: Java to IDL identifier mapping
Issue 1662: read_AbstractObject and write_AbstractObject
Issue 1736: Local stubs proposal
Issue 1780: JTS exceptions
Issue 1891: Need to #include orb.id
Issue 1894: Value methods not mapped in spec examples
Issue 1931: Need overloaded write_Value method on OutputStream
Issue 1957: Mapping of non-public types
Issue 1958: Mapping of java.rmi remoteException superclasses
Issue 1960: Mapping of Java arrays
Issue 1965: Eliminating server wait code
Issue 2081: Specifying code downloading
Issue 2082: Mapping of RuntimeException
Issue 2088: The mapping of java.lang.Class to IDL is not specified
Issue 2089: Custom marshalling wire format
Issue 2090: Mapping of Object, Serializable and Externalizable
Issue 2091: Support for serialPersistentFields
Issue 2092: RMI/ORB marshalling interface
Issue 2111: mapping from java.rmi Remote to CORBA::Object
Issue 2225: javax.rmi package use
Issue 2370: Mangling of Java long type not specified
Issue 2466: Mapping private Java methods to IDL
Issue 2467: Change write_* names in Util class
Issue 2468: IIOP/JRMP stubs name clash
Issue 2469: IDLEntity exception types as parameters and results
Issue 2470: Completion status missing from exception string
Issue 2471: RMI/IDL Tie changes
Issue 2472: Interfaces and values should be mapped consistently
Issue 2473: Mappings for non-conforming types
Issue 2474: Mapping for non-conforming class
Issue 2475: Definition of Stub.equals method
Issue 2476: IDLEntity types need to be boxed
Issue 2477: RMI Repository ID proposed change
Issue 2478: Replaceability of javax.* APIs
Issue 2479: Use of "java" as top-level IDL module
Issue 2480: export/unexport errors not well specified
Issue 2481: mapSystemException should preserve original exception
Issue 2482: Mapping of java.rmi.Remote
Issue 2483: NotSerializableException for RMI-IIOP
Issue 2484: Need read_Value(clz) on InputStream
Issue 2503: Need getTarget method on Tie interface
Issue 2504: Misleading wording in section 28.5.1.4
Issue 2505: ::java::lang::Exception is illegal IDL
Issue 2535: Mapping remote interface types to RMI-style repository IDs
Issue 2545: mapping of java.lang.Exception
Issue 2552: Treatment of classes with writeReplace/readResolve methods
Issue 2565: Mapping of Java constructors to init is broken
Issue 2804: stub classes can violate licensing and package sealing
Issue 2805:
Issue 2806:
Issue 2807:
Issue 2808:
Issue 2809:
Issue 2810:
Issue 2813:
Issue 2815:
Issue 2816:
Issue 2818:
Issue 2894: Security problem in JavaToIDL mapping
Issue 3093: PortableRemoteObject.narrow(null)
Issue 3117: Name mangling scheme broken.
Issue 3118: Boolean attributes
Issue 3151: Stream format problem for custom marshalled RMI types
Issue 3152: Tie.deactivate() exception handling
Issue 3160: Definition of serialVersionUID field
Issue 3200: Container/member name clashes
Issue 3433: No factory for javax.rmi.ClassDesc
Issue 3590: loader.loadClass() or Class.forName()?
Issue 3641: Java to IDL mapping contradictive to CORBA/IIOP 2.3.1
Issue 3670: Exception mapping needs fixing
Issue 3754: Java reverse mapping local case cannot properly support Portable Intercepto
Issue 3798: ValueHandler Interface
Issue 3857: Descriptions of readAny and writeAny not precise enough
Issue 3858: Package for PortableRemoteObjectDelegate
Issue 3969: Mapping of CORBA any and TypeCode
Issue 4004: Mapping CORBA minor codes to Java
Issue 4058: Mapping of Java byte constants to IDL
Issue 4296: javax.rmi.CORBA.Util.isLocal RemoteException condition(s) not specified
Issue 4319: Behavior of Java writeUTF/readUTF
Issue 4429: Issue with using the local stub with for example an EJB application
Issue 4497: Mapping subclasses of custom-marshaled Java classes to IDL
Issue 4591: New issue: Behavior of writeByte, writeChar, writeBytes, writeChars
Issue 4656: Mapping of ExceptionDetailMessage service context
Issue 4690: There is a typo on page 1-46.
Issue 4698: mapSystemException server mapping
Issue 4795: RMI-IIOP interop bet. J2SE 1.3 and 1.4
Issue 5330: Stream encoding for omitted optional custom data
Issue 5332: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID
Issue 5454: Java Codebase tagged component and POA
Issue 5723: Issue with ValueHandler.getRunTimeCodeBase and PRO.exportObject
Issue 5741: 1.2.3 RMI/IDL Remote Interfaces 2
Issue 5742: scheme for mapping names is pretty byzantine
Issue 5772: Name mapping rules for non-ASCII characters
Issue 5853: ORB shutdown should be configurable
Issue 5879: Custom Marshaling Format Clarification
Issue 5891: Guidance on RepositoryIDs for primitive types
Issue 5991: Request clarification on copyObject(s) semantics
Issue 6410: Custom marshalled abstract interfaces and Java/IDL
Issue 6411: Custom marshalled abstract interfaces and Java/IDL
Issue 6992: defaultWriteObject clarification
Issue 7217: Mapping CORBA activity exceptions to Java
Issue 7595: No wire format defined for java.lang.reflect.Proxy classes
Issue 10336: Section: 1.3, Page: 1-21

Issue 1578: Public method declarations in ResponseHandler interface (java2idl-rtf)

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.
 

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.
 

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.
 

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.
 
 

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.
 

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

There is a problem with implementing the deserialization of stubs
and the PortableRemoteObject.toStub method.  Both of these require
an ORB object to which the returned stub object will be connected
via its delegate.  However, there is no well-specified way to obtain
a suitable implicit ORB object in CORBA.

In the case of stub deserialization, it is not possible to pass an 
explicit ORB object to the deserialization operation.  In the case
of toStub, we do not wish to add an explicit ORB object because this
breaks the "portable RMI" programming model in which application
code refers only to RMI types and not to CORBA types.

Proposal:

Deserialization of javax.rmi.CORBA.Stub creates an "unconnected" stub.
Before being used, it must be connected to an ORB.  This will happen
automatically if the unconnected stub is written to a GIOP marshaling
stream by being passed to javax.rmi.CORBA.writeRemoteObject or
javax.rmi.CORBA.writeAbstractObject.  However, in other cases, the stub
must be connected explicitly.  To enable this, the method
   void connect(ORB orb) throws RemoteException { ... }
is added to the javax.rmi.CORBA.Stub class, and the method
   static void connect(java.rmi.Remote unconnected, 
                       java.rmi.Remote connected)
               throws RemoteException { ... }
is added to the javax.rmi.PortableRemoteObject class.

The Stub.connect method throws RemoteException if called on a stub that
is already connected to an ORB (i.e., has a delegate set).  Otherwise,
a delegate is created for this stub and the specified ORB.  This method
is not intended to called directly by application code; instead,
application code should call the PortableRemoteObject.connect method,
which will in turn call the Stub.connect method.  This allows the
application code to remain portable between IIOP and JRMP.

The PortableRemoteObject.connect method may take an RMI/IDL stub or
an exported RMI/IDL implementation object as its "unconnected" and
"connected" parameters.  If "unconnected" is a connected object 
(i.e., an RMI/IDL CORBA stub with a delegate or an implementation
object with an RMI/IDL tie that has been associated with an ORB),
then a RemoteException is thrown.  Similarly if "connected" is an
unconnected object (i.e., an RMI/IDL CORBA stub without a delegate
or an implementation object whose RMI/IDL tie has not been associated
with an ORB), then a RemoteException is thrown.  Otherwise, "unconnected"
is connected to the same ORB as "connected" by setting its delegate if
it is a stub or by associating its tie with an ORB if it is an
implementation object.

RMI/IDL implementation objects may be connected implicitly by being
passed to javax.rmi.CORBA.writeRemoteObject or
javax.rmi.CORBA.writeAbstractObject, or explicitly by means of the
PortableRemoteObject.connect method.  Connecting an implementation
object is not the same as exporting it, and RMI/IDL implementation 
objects may be unconnected when first exported.  RMI/IDL implementation
objects are implicitly connected when they are exported to JRMP, and
RMI-JRMP stubs are implicitly connected when they are created.

The stub returned by PortableRemoteObject.toStub has the same
connection status as the target implementation object passed to toStub. 
So if the target object is connected, the returned stub is connected
to the same ORB.  If the target object is unconnected, the returned
stub is unconnected.

The javax.rmi.CORBA.Stub.writeObject method writes the following data
to the serialization stream:
 1. int - length of IOR type id  
 2. byte[] - IOR type ID encoded using ISO 8859-1
 3. int - number of IOR profiles
 4. For each IOR profile:
    a. int - profile tag
    b. int - length of profile data
    c. byte[] - profile data

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.
 

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
 

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
 

 resolved, close issue

Summary: 10. Need to emit ID pragmas after declarations
 

Summary: Lexigraphic sort for field names is before mangling
 
     Proposed resolution: clarify section 5.5.6
 

Summary: 12. Narrow signature does not allow use for abstract interfaces
 
     Proposed resolution: return java.lang.Object
 

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

 In section 5.7.4, example IDL, change

Summary:  Can toStub take a stub?
 
     Proposed resolution: yes, in which case it"s a no-op.
 

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

 received issue

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
 
 

 issue resolved and fixed

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
 

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

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

 No.--close issue

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
 
 

Summary: 25. Should exportObject throw exceptions?
 

 received issue

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

 received issue

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. 
 

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

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.
 

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.
 

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.
 

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.
 

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.
 
 
 

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.
 
 

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.  
 
 

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
 

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.
 
 

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.
 
 
 

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?
 

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.
 

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.
 

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.
 

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.
 

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.
 

 issue resolved and closed

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.
 

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?
 

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
 

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.
 

 Adopted proposal:

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.
 

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.
 

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.
 

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

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.
 

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.
 

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.
 

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.
 
 

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

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.
 

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

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

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.
 

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.
 

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.
 

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.