Issues for Java to IDL RTF Discussion Mailing List

To comment on any of these issues, send email to java2idl-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

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)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1589: orb() method on InputStream (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1590: Marshalling of Any, Context, Principal, and TypeCode (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1591: Default Constructor for Stubs (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1592: How to make IDLEntity types serializable (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1593: Obtaining a default ORB (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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).
 

Resolution: Closed, accepted
Revised Text:
Actions taken:
June 29, 1998: received issue
June 4, 1999: closed issue

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


Issue 1594: SerializationInputStream and SerializationOutputStream (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1595: Unicode example needs fixing (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1596: Mapping for nested sequences --- fix example (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:
 resolved, close issue


Issue 1597: Need to emit ID pragmas after declarations (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 10. Need to emit ID pragmas after declarations
 

Resolution:
Revised Text: resolved, close issue
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1598: Lexigraphic sort for field names is before mangling (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Lexigraphic sort for field names is before mangling
 
     Proposed resolution: clarify section 5.5.6
 

Resolution:
Revised Text: clarify section 5.5.6
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1599: Narrow signature does not allow use for abstract interfaces (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 12. Narrow signature does not allow use for abstract interfaces
 
     Proposed resolution: return java.lang.Object
 

Resolution:
Revised Text: return java.lang.Object
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1600: Section 5.7.4 : mapped IDL issue (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: In section 5.7.4 the mapped IDL for Thrower includes:
        FruitbatException getLastException();
     It should be
        readonly attribute ::omega::FruitbatException lastException;
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:
 In section 5.7.4, example IDL, change



Issue 1601: Can toStub take a stub? (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:  Can toStub take a stub?
 
     Proposed resolution: yes, in which case it"s a no-op.
 

Resolution:
Revised Text: yes, in which case it"s a no-op.
Actions taken:
June 29, 1998: received issue
February 24, 1999: closed issue

Discussion:


Issue 1602: Does toStub return most derived stub? (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 15. does toStub return most derived stub, or iterate looking for one?
 

Resolution:
Revised Text: resolved, close issue
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:
 received issue


Issue 1603: Clarify rules for mapping server-side errors and exceptions (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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
 
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:
 issue resolved and fixed


Issue 1604: The generated IDL in A2 needs to be changed (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1606: mangling rule for name clashes in IDL needs to be defined (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Need to define a mangling rule for name clashes in IDL between 
     constant/method/attribute.
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1607: Do we need to protect non-generated IDL files against multiple inclusion? (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Do we need to protect non-generated IDL files against multiple
     inclusion?
 
     Proposed resolution: no protection
 
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:
 No.--close issue


Issue 1608: Rules in section 7.4.4 for toStub IIOP/JRMP search not correct (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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
 
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1609: Should exportObject throw exceptions? (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 25. Should exportObject throw exceptions?
 

Resolution:
Revised Text: resolved, close issue
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:
 received issue


Issue 1610: PortableRemoteObject toStub should throw NoSuchObject Exception (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:  PortableRemoteObject.toStub should throw NoSuchObjectException if object
     has not been exported.
 

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue

Discussion:
 received issue


Issue 1619: Abstract Interfaces issue (java2idl-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
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. 
 

Resolution:
Revised Text:
Actions taken:
June 30, 1998: received issue
February 24, 1999: closed issue

Discussion:


Issue 1620: Omission in section 5.4.5 (java2idl-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
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".
 

Resolution:
Revised Text:
Actions taken:
June 30, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1621: Stub methods for hashCode, equals and toString (java2idl-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
June 30, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1640: Should Portability APIs throw SystemException? (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
July 8, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1641: Mapping of Java names that are IDL keywords (java2idl-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
July 8, 1998:
February 23, 1999: closed issue

Discussion:


Issue 1642: Java to IDL identifier mapping (java2idl-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
July 8, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1662: read_AbstractObject and write_AbstractObject (java2idl-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
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.
 
 
 

Resolution:
Revised Text:
Actions taken:
July 10, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1736: Local stubs proposal (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 
 

Resolution: closed, accepted
Revised Text: dd the following methods to the javax.rmi.CORBA.Util class: public static RemoteException wrapException(Throwable obj) { ... } The wrapException method wraps an exception thrown by an implementation method. It returns the corresponding client-side exception. See section 28.4.8.1 for details. public static Object copyObject (Object obj, ORB orb) throws RemoteException { ... } public static Object[] copyObjects (Object[] obj, ORB orb) throws RemoteException { ... } The copyObject method is used by local stubs to copy an actual parameter, result object, or exception. The copyObjects method is used by local stubs to copy any number of actual parameters, preserving sharing across parameters as necessary to support RMI/IDL semantics. The actual parameter Object array holds the method parameter objects that need to be copied, and the result Object array holds the copied results. The stubs are required to call the above methods (or generate equivalent inline code) to handle Remote objects correctly. public static boolean isLocal(Stub s) throws java.rmi.RemoteException { ... }; This method has the same semantics as the ObjectImpl._is_local method, except that it can throw a java.rmi.RemoteException. Add the following new section after section 28.5.2.1: 28.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 javax.rmi.CORBA.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(x) 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 _servant_preinvoke method returns non-null if and only if an optimized local call may be used. It performs any security checking that may be necessary. Local stubs are responsible for performing all copying of method parameters, results and exceptions that is necessary to provide remote/local-transparent RMI/IDL semantics. The following is an example of a stub class that provides this optimized call path. 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)) { InputStream in = null; try { try { OutputStream out = _request("echo", true); out.write_long(x); in = _invoke(out); return in.read_long(); } catch (ApplicationException ex) { in = ex.getInputStream(); String id = in.read_string(); if (id.equals("IDL:BoomerangEx/1.0")) { throw (Boomerang) ((org.omg.CORBA_2_3.portable.InputStream)in). read_Value(); } else { throw new java.rmi.UnexpectedException(id); } } catch (RemarshalException ex) { return echo(x); } } catch (SystemException ex) { throw javax.rmi.CORBA.Util.mapSystemException(ex); } finally { _releaseReply(in); } } else { ServantObject so = _servant_preinvoke("echo", Aardvark.class); if (so == null) return echo(x); try { return ((Aardvark)so.servant).echo(x); } catch (Throwable ex) { Throwable ex2 = (Throwable)Util.copyObject(ex, _orb()); if (ex2 instanceof Boomerang) throw (Boomerang)ex2; else throw Util.wrapException(ex2); } finally { _servant_postinvoke(so); } } } }
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1780: JTS exceptions (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.  
 
 

Resolution:
Revised Text:
Actions taken:
August 6, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1891: Need to #include orb.id (java2idl-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
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
 

Resolution: :CORBA::WStringValue but does not define this type.
Revised Text:
Actions taken:
August 26, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1894: Value methods not mapped in spec examples (java2idl-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
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.
 
 

Resolution:
Revised Text:
Actions taken:
August 27, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1931: Need overloaded write_Value method on OutputStream (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 
 
 

Resolution: closed, accepted
Revised Text: RMI/IDL arrays must be marshaled with a repository ID indicating their runtime type. Also, RMI/IDL arrays must be demarshaled according to the type specified in the repository ID of the boxed valuetype in the GIOP encoding.
Actions taken:
September 3, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1957: Mapping of non-public types (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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?
 

Resolution:
Revised Text:
Actions taken:
September 15, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1958: Mapping of java.rmi remoteException superclasses (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
September 15, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1960: Mapping of Java arrays (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text: :org::omg::sequences::seq_seq_foo.
Actions taken:
September 16, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 1965: Eliminating server wait code (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
September 16, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 2081: Specifying code downloading (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: Requirements The spec should allow codebase annotation when marshalling in Java, and should specify how the annotation is selected for RMI-IIOP values and object references. The spec should mandate code downloading using the codebase annotation for Java demarshalling of RMI-IIOP values, stubs and ties, and should specify the classloader semantics. Original Proposal This proposal is defined in terms of JDK 1.2 APIs. When sending from Java, for any given java.lang.Class instance C, the codebase annotation used must be equivalent to the codebase returned by: java.rmi.server.RMIClassLoader.getClassAnnotation(C); (with the string parsed into space-separated URL strings). When receiving in Java, for any given class name N, if there is no codebase annotation, or if the system property java.rmi.server.useCodebaseOnly is equal to "true" ignoring case, then the Java class that this name resolves to must be the same as that returned by: java.rmi.server.RMIClassLoader.loadClass(N); Otherwise, if the codebase annotation is CA, then the Java class that this name resolves to must be the same as that returned by: java.rmi.server.RMIClassLoader.loadClass(CA, N); (with CA turned into a single string with space as separator). Ammended Proposal Class downloading is supported for stubs, ties, values, and value helpers. The implementation is based on the original proposal, with enhancements to enable implementation on JDK 1.1.6 APIs, to enable transmission of codebase information on the wire for stubs and ties, and to enable usage of pre-existing ClassLoaders when relevant. Definitions "codebase" - A java.lang.String containing a space-separated array of URLs (e.g. "http://acme.com/classes" or "http://abc.net/classes http://abc.net/ext/classes"). [Note: the space-separated representation is preferred over a String[] representation in order to avoid conversion when calling the 1.2 JDK RMI APIs.] "localCodebase" - The System Property "java.rmi.server.codebase" whose value is a codebase or null. Defaults to null. "remoteCodebase" - The codebase transmitted from a remote system. May be null. "useCodebaseOnly" - The System Property "java.rmi.server.useCodebaseOnly" whose value is either "true" or "false". Defaults to "false". If "true" (ignoring case), any remote codebase is ignored and only the local codebase used. "loadingContext" - A class that specifies a context within which class loading is initiated. May be null. Codebase Selection The following method is added to the javax.rmi.CORBA.Util class: public static String getCodebase(java.lang.Class clz) { ... } On JDK 1.2, this method returns the same string as: java.rmi.server.RMIClassLoader.getClassAnnotation(clz) On JDK 1.1, this method works as follows: 1. If the name of clz starts with "java.", then return null, else... 2. If clz has a ClassLoader with a URL security context, then return this URL, else... 3. If there is a security manager with a URL security context, then return this URL, else... 4 Return localCodebase. When sending RMI/IDL values from Java, the codebase transmitted over GIOP must be the codebase that this method would return for the value's class. When sending RMI/IDL object references from Java, the codebase transmitted over GIOP is selected by calling the org.omg.CORBA_2_3.portable.ObjectImpl._get_codebase method (see below) on the stub object. Codebase Transmission For values and value helpers, the OBV specification defines the wire format for codebase transmission. For stubs and ties, the codebase is transmitted as a TaggedComponent in the IOR profile, where the component_data is a CDR encapsulation of the codebase written as an IDL string. The codebase is a blank-separated list of one or more URLs. [NOTE: component_id needs to be assigned by the Interoperability RTF.] In all cases, the SendingContext.RunTime object may provide a default codebase that is used if not overridden by a more specific codebase encoded in a valuetype or IOR. For object references created using InputStream.read_Object or InputStream.read_Abstract, the transmitted codebase is stored in the object reference (stub) and can be retrieved subsequently using the org.omg.CORBA_2_3.portable.ObjectImpl._get_codebase method, described below. If no codebase was transmitted, localCodebase is stored in the object reference (stub). Codebase Access In the event that PortableRemoteObject.narrow() must load a stub, a new API is required to extract codebase information from the original stub. This API is also used by the OutputStream methods write_Object and write_Abstract to obtain the codebase to be transmitted in the new TaggedComponent. The following method is added to org.omg.CORBA_2_3.portable.ObjectImpl, which is a newly created subclass of org.omg.CORBA.portable.ObjectImpl: /** Returns the codebase for this object reference. * @return the codebase as a space delimited list of url strings or * null if none. */ public java.lang.String _get_codebase() { return ((org.omg.CORBA_2_3.portable.Delegate)_get_delegate()).get_codebase(this); } and a corresponding method is added to org.omg.CORBA_2_3.portable.Delegate, which is a newly created subclass of org.omg.CORBA.portable.Delegate: /** Returns the codebase for the object reference provided. * @param self the object reference whose codebase needs to be returned. * @return the codebase as a space delimited list of url strings or * null if none. */ public java.lang.String get_codebase(org.omg.CORBA.Object self) { return null; } The javax.rmi.CORBA.Stub class is changed to extend org.omg.CORBA_2_3.portable.ObjectImpl instead of org.omg.CORBA.portable.ObjectImpl. Codebase Usage The following method is added to the javax.rmi.CORBA.Util class: public static Class loadClass(String className, String remoteCodebase, Class loadingContext) throws ClassNotFoundException { ... } On JDK 1.2, this method works as follows: 1. Find the first non-null ClassLoader on the call stack, and attempt to load the class using this ClassLoader. If this fails... 2. If remoteCodebase is non-null and useCodebaseOnly is false, then call java.rmi.server.RMIClassLoader.loadClass(remoteCodebase, className). 3. If remoteCodebase is null or useCodebaseOnly is true, then call java.rmi.server.RMIClassLoader.loadClass(className). 4. 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). 5. If a class was successfully loaded by step 1, 2, 3, or 4, then return the loaded class. On JDK 1.1, this method works as follows: 1. If className is an array type, extract the array element type. If this is a primitive type, then call Class.forName(className), else proceed using the array element class name as className. 2. Search the call stack for the first non-null ClassLoader. If a ClassLoader is found, then attempt to load the class using this ClassLoader, else attempt to load the class using Class.ForName(className). If this fails... 3. If remoteCodebase is non-null and useCodebaseOnly is false, then call java.rmi.server.RMIClassLoader.loadClass(codebaseURL, className) for each remote codebase URL in the remoteCodebase string until the class is found. 4. If remoteCodebase is null or useCodebaseOnly is true, then call java.rmi.server.RMIClassLoader.loadClass(className). 5. If a class was not successfully loaded by step 1, 2, 3, or 4, and loadingContext and loadingContext.getClassLoader() are both non-null, then call loadingContext.getClassLoader().loadClass(className). 6. If a class was successfully loaded by step 1, 2, 3, 4, or 5, then return the loaded class, unless the className parameter was a non-primitive array type, in which case return a suitably dimensioned array class for the element class that was loaded. When loading classes for RMI/IDL values, stubs, and ties, the class loaded must be be the same as that returned by this method except where stated below. For values and their helper classes, remoteCodebase is the codebase that was transmitted in the GIOP valuetype encoding (if any), or else the codebase obtained from the SendingContext.RunTime object associated with the IIOP connection. loadingContext is null or the expected value class, if known. For ties created by PortableRemoteObject.exportObject, remoteCodebase is obtained by calling Util.getCodebase on the class of the implementation object. loadingContext is null. For stubs created by InputStream.read_Object(), remoteCodebase is the codebase transmitted in the new IOR TaggedComponent (if any), or else the codebase obtained from the SendingContext.RunTime object associated with the IIOP connection. This method may either create a generic stub for subsequent narrowing or may attempt to create a stub by loading a stub class that matches the RepositoryId in the IOR. loadingContext is null. For stubs created by InputStream.read_Object(clz), remoteCodebase is the same as for InputStream.read_Object(). The implementation of read_Object(clz) may either use the actual parameter clz to create a stub or may attempt to create a stub by loading a stub class that matches the RepositoryId in the IOR. loadingContext is clz. For stubs created by PortableRemoteObject.narrow, remoteCodebase is obtained from the narrowFrom object by calling the ObjectImpl._get_codebase method. For stubs created by PortableRemoteObject.toStub, Util.writeRemoteObject or Util.writeAbstractObject, remoteCodebase is obtained by calling Util.getCodebase on the class of the implementation object. loadingContext is narrowFrom. For all stubs, remoteCodebase is stored by the Delegate and can be retrieved subsequently using the org.omg.CORBA_2_3.portable.ObjectImpl._get_codebase method. Other Changes In section 28.3.5.11, change the definition of javax.rmi.CORBA.ClassDesc to: // Java package javax.rmi.CORBA; public class ClassDesc implements java.io.Serializable { private String repid; private String codebase; // blank-separated list of URLs }
Actions taken:
October 14, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2082: Mapping of RuntimeException (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
October 14, 1998: received issue
February 23, 1999: closed issue

Discussion:
 issue resolved and closed


Issue 2088: The mapping of java.lang.Class to IDL is not specified (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
October 16, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 2089: Custom marshalling wire format (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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?
 

Resolution: Closed, accepted
Revised Text: In section 28.3.5.6, change the mapping for Serializable classes with a writeObject method so that non-public fields are mapped to IDL private fields in the custom valuetype. Add the following section after section 28.3.5.6: 28.3.5.7 Custom Marshaling Format When an RMI/IDL value type is custom marshaled over GIOP, the following data is transmitted: 1. Serializable objects with a writeObject method. octet Format version. Always 1. boolean True if defaultWriteObject was called, false otherwise. ... (optional) Data written by defaultWriteObject. The ordering of the fields is the same as the order in which they appear in the mapped IDL valuetype, and these fields are encoded exactly as they would be if the class did not have a writeObject method. ... (optional) Additional data written by writeObject, encoded as specified below. 2. Externalizable objects. octet Format version. Always 1. ... (optional) Data written by writeExternal, encoded as specified below. Primitive Java types are marshaled as their corresponding IDL primitives (see section 28.3.3). 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. RMI/IDL stubs, RMI/IDL remote implementations, and IDL stubs are marshaled as object references (IORs). All other Java objects are marshaled as value types. The value type encoding is determined from the object's runtime type by applying the mappings specified in sections 28.3.5, 28.3.6, and 28.3.7. This encoding ensures that primitive data is marshaled using a chunked encoding and cannot incorrectly be read in as object data. The GIOP specification states that custom marshaled types must be marshaled using a chunked encoding. Therefore, if primitive data is written followed by a value object, the currently open chunk for the primitive data will automatically be ended before the value tag is written. This prevents primitive read operations from consuming a value header (chunk underflow), and also prevents read_Value operations from consuming primitive data (chunk overflow). This mechanism does not prevent primitive reads from consuming non-matching primitive data, which is also true for Java deserialization. However, it is possible for primitive reads to consume IOR data, and vice versa. Reading an incorrect IOR will either cause a MARSHAL error or in rare cases create an unusable object reference (e.g., incorrect host name, port number, or object key). Since neither of these violates the integrity of the local system, this small exposure is acceptable.
Actions taken:
October 16, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2090: Mapping of Object, Serializable and Externalizable (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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
 

Resolution:
Revised Text:
Actions taken:
October 16, 1998: received issue
February 23, 1999: closed issue

Discussion:


Issue 2091: Support for serialPersistentFields (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
October 16, 1998: received issue
May 16, 2006: closed issue

Discussion:
 Adopted proposal:



Issue 2092: RMI/ORB marshalling interface (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: 1. Add the following methods to ValueHandler: java.lang.String getRMIRepositoryID(java.lang.Class clz); boolean isCustomMarshaled(java.lang.Class clz); SendingContext.CodeBase getRunTimeCodeBase(); java.io.Serializable writeReplace(java.io.Serializable value); When marshaling an RMI value, the ORB stream must call Util.getCodeBase to get the codebase string, ValueHandler.getRMIRepositoryID to get the repository ID string, and ValueHandler.isCustomMarshaled to see if the value is custom marshaled and therefore requires a chunked encoding. The ORB stream writes the value tag, codebase (if any), and repository ID. It calls ValueHandler.write_Value to write the state of the value. The ORB stream deals with nulls, indirections, chunking, and end tags. The ORB obtains the SendingContextRunTime service context from the ValueHandler by calling the ValueHandler.getRunTimeCodeBase method. Clients must send this service context on the first GIOP request that flows over a connection that may be used to send RMI values to the server. Servers must send this service context on the first GIOP reply that flows over a connection that may be used to send RMI values to the client. The ORB calls the writeReplace method before calling writeValue. The result from calling this method is passed to ValueHandler.writeValue unless either a. it is a previously marshalled value, in which case it is marshalled as an indirection, or b. its class implements org.omg.CORBA.Object, in which case it is marshalled as an object reference. An ORB stream instance must only call writeReplace once for each value that it marshals. 2. Change the names of the ValueHandler read_Value and write_Value methods to readValue and writeValue to be consistent with Java method naming conventions. 3. Change the readValue method of ValueHandler to the following signature: java.io.Serializable readValue( org.omg.CORBA.portable.InputStream in, int offset, java.lang.Class clz, String repositoryID, org.omg.SendingContext.RunTime sender) { ... } When demarshaling an RMI value, the ORB stream must read the value tag, codebase (if any), and repository ID. The ORB stream calls Util.loadClass to load the value's class, passing the Java class name contained in the RMI-style repository ID and the codebase string from the value's GIOP encoding (if present) or the SendingContextRunTime service context. The ORB stream calls ValueHandler.readValue to read the state of the value, passing the current stream offset, the class returned by loadClass, the repository ID, and the sender's SendingContext.RunTime object reference. The repository ID is needed so that the ValueHandler can determine if the class passed in is structurally identical to the class used by the sender to marshal the value. The ORB stream deals with nulls, indirections, chunking, and end tags. 4. Add a new exception org.omg.CORBA.portable.IndirectionException: public class IndirectionException extends org.omg.CORBA.SystemException { int offset; } The ORB input stream throws this exception when it is called to demarshal a value that is encoded as an indirection that is in the process of being demarshalled. This can occur when the ORB stream calls the ValueHandler to demarshal an RMI value whose state contains a recursive reference to itself. Because the top-level ValueHandler.readValue call has not yet returned a value, the ORB stream's indirection table contains no entry for an object with the stream offset specified by the indirection tag. This stream offset is returned in the exception's "offset" field. When the ValueHandler receives this exception, it stores the stream offset together with a reflective object that can be used later to update the field to which the result of calling the ORB stream's read_Value method would have been assigned. These [offset,fieldref] pairs are stored in a "fixup" table that is associated with the InputStream that the ValueHandler is using for its current demarshaling operation. Before the ValueHandler.readValue method returns to the ORB stream, it checks this fixup table for an entry with the offset passed in on the readValue call. If an entry matching the offset is found, it performs a fixup using the reflective fieldref object and the value it is about to return, then removes this fixup entry. When the top-level readValue call returns, the fixup table should be empty, indicating that all fixups have successfully been performed. If the table is not empty, this indicates an incorrect indirection in the GIOP value encoding, and a MARSHAL exception is thrown to indicate this. This scheme deals successfully with recursive references without introducing new API calls and with minimal overheads in the common case of a value that does not contain recursive references. In this case, the only overhead is the need to pass the "offset" parameter on the call to ValueHandler.readValue.
Actions taken:
October 16, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2111: mapping from java.rmi Remote to CORBA::Object (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: See revised text below.
Revised Text: In section 1.5.1.4, at the end of the paragraphs describing writeRemoteObject and writeAbstractObject, add the sentence: "This method cannot be used to write a JRMP object reference to an output stream."
Actions taken:
October 20, 1998: received issue
May 24, 2001: closed issue

Discussion:


Issue 2225: javax.rmi package use (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, no change
Revised Text:
Actions taken:
November 19, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2370: Mangling of Java long type not specified (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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".
 

Resolution: Closed, accepted
Revised Text: In mangled overloaded IDL method names, the IDL type "long long" shall appear as "long_long".
Actions taken:
February 2, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2466: Mapping private Java methods to IDL (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2467: Change write_* names in Util class (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2468: IIOP/JRMP stubs name clash (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2469: IDLEntity exception types as parameters and results (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 
 

Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2470: Completion status missing from exception string (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: Add the following to the end of the description of the detail string for RMI Exceptions mapped from CORBA system exceptions: . followed by a space . followed by the completion status: one of "Yes" "No" "Maybe"
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2471: RMI/IDL Tie changes (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2472: Interfaces and values should be mapped consistently (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: a. Change the mapping for exceptions on methods of value types to not map RemoteException, RuntimeException and their subclasses to IDL. b. Change the mapping for property accessors on value types to be the same as on remote interfaces. c. Changes a and b also apply to abstract interfaces.
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2473: Mappings for non-conforming types (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The mapping for methods and constants in non-conforming types
 should be specified (by cross-reference to the words for value types).
 

Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2474: Mapping for non-conforming class (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2475: Definition of Stub.equals method (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2476: IDLEntity types need to be boxed (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: 28.2.1 add two new bullets - is a conforming CORBA object reference (see section 28.2.7) - is a conforming IDL entity (see section 28.2.8) Add new section 28.2.7 CORBA Object References A conforming CORBA object reference is either - the Java interface org.omg.CORBA.Object or - a Java interface that extends org.omg.CORBA.Object directly or indirectly and conforms to the rules specified in the Java Language mapping (i.e., could have been generated by applying the mapping to an IDL definition). Add new section 28.2.8 IDL Entities A Java class is a conforming RMI/IDL type if it extends org.omg.CORBA.portable.IDLEntity and conforms to the rules specified in the Java Language mapping (i.e., could have been generated by applying the mapping to an IDL definition), and is not an IDL user exception. Add 2 new bullets to 28.3.1 after the 5th bullet - RMI/IDL exceptions - CORBA object references - IDL entities Renumber the following sections as below: 28.3.8->28.3.10, 28.3.9->28.3.11, 28.3.10->28.3.12 Change section 28.3.6 globally replace ::org::omg::sequences with ::org::omg::boxedRMI and org_omg_sequences with org_omg_boxedRMI After the fourth paragraph, insert a new paragraph: For each "boxed" value type generated for a Java array, a #pragma ID is generated to specify an RMI Hashed Format repository ID for the IDL type. In the example in section 28.3.6.2, add the following line: #pragma ID seq1_Dolphin "RMI:[Lomega.Dolphin;:ABCDEF0123456789" Add new section 28.3.8 Mapping CORBA Object References A CORBA object reference is mapped directly to its corresponding IDL interface or to Object if it is org.omg.CORBA.Object. Add new section 28.3.9 Mapping IDL Entities An IDL entity that is not a CORBA object reference is mapped to a "boxed" value type containing the IDL entity. The containing module for the boxed IDL entity is determined by the IDL entity's container. A module name is formed by taking the ::org::omg::boxedIDL prefix and appending the IDL entity's container's fully scoped name. A boxed value type corresponding to the IDL entity is defined within this module. The name of the value type is the same as the name of the IDL definition it is boxing. For example, assume we have the following IDL and the Java class that results from applying the forward mapping: // IDL module hello { struct world { short x; }; }; // Java package hello; public final class world implements org.omg.CORBA.portable.IDLEntity { ... } Now assume that hello.world is used as an argument to a method or as a member of an RMI/IDL value type. The Java class hello.world is mapped as follows: hello.world ==> in the module ::org::omg::boxedIDL::hello define valuetype world ::hello::world; #pragma ID world "RMI:[Lhello.world;:1234567890ABCDEF" The exact mechanism by which the IDL for ::hello::world is created is a tools issue and is not specified. (Note to rtf: Specifying a conversion algorithm will effectively require creating a reversible mapping, which is not the intent of this proposal. There are many ways this can be achieved. One mechanism would be to pass the original IDL file in the command line of the tool, and read the definitions from the IDL file.) Preprocessor guards are placed for these definitions in the same way as they are done for mapping arrays. Add new section 28.4.7 (move all sections from 28.4.7 up by one). 28.4.7 Marshaling IDL entities Marshaling and demarshaling of IDL entities is done by calling write_Value(java.io.Serializable) and read_Value() on the portable output and input streams respectively.
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2477: RMI Repository ID proposed change (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: Resolution: make it so. This has been modified to correct errors in the RMI format specification and is being put up for vote to approve the mdified and error corrected version. Revised Text: In section 10.6, change text added by resolution to issue 2329 from: This specification defines four formats: one derived from OMG IDL names, one that uses OMG IDL names and Java serialization version UIDs, one that uses DCE UUIDs, and another intended for short-term use, such as in a development environment. to the following text: This specification defines four formats: one derived from OMG IDL names, one that uses Java class names and Java serialization version UIDs, one that uses DCE UUIDs, and another intended for short-term use, such as in a development environment. In section 10.6.2, change the grammar from RMI: <scoped name> : <hash code> [ : <serialization version UID> ] to: RMI: <class name> : <hash code> [ : <serialization version UID> ] Replace the following paragraph by: The class name is a Java class name as returned by the getName method of java.lang.Class. Any characters not in ISO Latin 1 are replaced by "\U" followed by the 4 hexadecimal characters (in upper case) representing the Unicode value. Change the examples to: RMI:foo.bar:1234567812345678 RMI:foo.bar;:1234567812345678:ABCD123456781234 And an example of a Java array of valuetype ::foo::bar would be RMI:[Lfoo.bar;:1234567812345678:ABCD123456781234 For a Java class x\u03bCy which contains a Unicode character not in ISO Latin 1, an example RepositoryId is RMI:foo.x\U03BCy:8765432187654321
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
September 16, 1999: closed issue

Discussion:


Issue 2478: Replaceability of javax.* APIs (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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).
 

Resolution: Closed, accepted
Revised Text: This is a proposal of a framework to enable vendor-specific implementations of the Java Language to IDL Mapping Portability Interfaces. The effected classes are: javax.rmi.PortableRemoteObject javax.rmi.CORBA.Stub javax.rmi.CORBA.Util These classes are extended to optionally delegate their methods to separate implementation classes which can be provided by ORB vendors. 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 { void mapSystemException(org.omg.CORBA.SystemException ex) throws java.rmi.RemoteException; void writeAny(org.omg.CORBA.portable.OutputStream out, java.lang.Object obj); java.lang.Object readAny(org.omg.CORBA.portable.InputStream in); void write_RemoteObject(org.omg.CORBA.portable.OutputStream out, java.lang.Object obj); void write_AbstractObject(org.omg.CORBA.portable.OutputStream out, java.lang.Object obj); void registerTarget(javax.rmi.CORBA.Tie tie, java.rmi.Remote target); void unexportObject(java.rmi.Remote target); javax.rmi.CORBA.Tie getTie(java.rmi.Remote target); javax.rmi.CORBA.ValueHandler createValueHandler(); } public interface PortableRemoteObjectDelegate { void exportObject(Remote obj) throws RemoteException; Remote toStub (Remote obj) throws NoSuchObjectException; void unexportObject(Remote obj) throws NoSuchObjectException; java.lang.Object narrow (java.lang.Object narrowFrom, java.lang.Class narrowTo) throws ClassCastException; void connect (Remote unconnected, Remote connected) throws RemoteException; } The implementation delegate class for Stub must implement the following new interface for per-instance delegation: package javax.rmi.CORBA; public interface StubDelegate { int hashCode(Stub self); boolean equals(Stub self, java.lang.Object obj); String toString(Stub self); void writeObject(Stub self, java.io.ObjectOutputStream s); void readObject(Stub self, java.io.ObjectInputStream s); void connect(Stub self, ORB orb) throws RemoteException; } Sun will provide default implementations of the methods in the standard API classes. Alternate implementations are enabled by setting system properties or placing entries in the orb.properties file. The names of the new system properties are: javax.rmi.CORBA.PortableRemoteObjectClass javax.rmi.CORBA.UtilClass javax.rmi.CORBA.StubClass For security reasons, each replaceable API class reads its implementation delegate class system property at static initialization time and uses this information to set up implementation delegation if this has been specified. The delegation arrangement thus established cannot be changed subsequently. The search order for delegate class names is: 1.The system properties. 2.The orb.properties file. For each implementation delegate class, an instance is created using the Class.newInstance() method. For the PortableRemoteObject and Util delegate classes, this is a singleton instance. For the Stub delegate class, there is one delegate instance per stub object. The methods in the standard API classes test if a delegate instance exists and if so, forward the method call on to the delegate instance.
Actions taken:
February 22, 1999: received issue
September 16, 1999: closed issue

Discussion:


Issue 2479: Use of "java" as top-level IDL module (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, no change
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2480: export/unexport errors not well specified (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.  
 

Resolution: Closed, accepted
Revised Text: 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 to 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.
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2481: mapSystemException should preserve original exception (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The RemoteException returned by mapSystemException should preserve
 the original CORBA system exception as the detail field.
 

Resolution: Closed, accepted
Revised Text: The RemoteException returned by mapSystemException must preserve the original CORBA system exception as the detail field.
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2482: Mapping of java.rmi.Remote (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: When java.rmi.Remote appears as an RMI/IDL argument or result type, it is mapped to the following IDL type: module java { module rmi { typedef Object Remote; }; }; java.rmi.Remote as a java value member is also mapped this way In section 28.2.3, replace numbered item 1 by: The interface is or inherits from java.rmi.Remote either directly or indirectly.
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2483: NotSerializableException for RMI-IIOP (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: In section 28.4.8, say that the CORBA BAD_PARAM system exception maps to java.rmi.MarshalException. If the BAD_PARAM minor code is 6 (as proposed to the core RTF in issue 2502), then the nested exception is java.io.NotSerializableException. For all other minor codes, the nested exception is the original BAD_PARAM.
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2484: Need read_Value(clz) on InputStream (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: The following method is added to org.omg.CORBA_2_3.portable.InputStream: java.io.Serializable read_value(Class clz); This method unmarshals a value type from the input stream. clz is the declared type of the value to be unmarshaled. The following method is added to org.omg.CORBA_2_3.portable.OutputStream: void write_value(java.io.Serializable value, Class clz); This method marshals a value type to the output stream. value is the value to be marshaled, and clz is the declared type of the value to be marshaled.
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2503: Need getTarget method on Tie interface (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: Add the following method to javax.RMI.CORBA.Tie: java.rmi.Remote getTarget(); The getTarget method must be implemented by Tie classes. It returns the registered target implementation object for the tie.
Actions taken:
March 3, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2504: Misleading wording in section 28.5.1.4 (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: Change the following text: However, if obj is an RMI/IDL implementation object .... to: However, if obj is an exported RMI/IDL implementation object ....
Actions taken:
March 3, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2505: ::java::lang::Exception is illegal IDL (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: Change the IDL valuetype to ::java::lang::_Exception.
Actions taken:
March 3, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2535: Mapping remote interface types to RMI-style repository IDs (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: In the mapping from RMI remote interfaces to IDL interfaces, add a #pragma ID specifying an RMI: format repository ID derived from the Java interface name using the rules specified in chapter 10, with a hash code of zero and no SUID.
Actions taken:
March 15, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2545: mapping of java.lang.Exception (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution: Closed, accepted
Revised Text: Section 28.2.3 Change #4 to: 4. All checked exception classes used in method declarations (other than java.rmi.RemoteException and its subclasses) are conforming RMI/IDL exception types (see "RMI/IDL Exception Types" on page 28-5). Change the footnote for this to: 1. Because unchecked exception classes and java.rmi.RemoteException and its subclasses are not mapped to IDL exceptions, it is not necessary for them to be conforming RMI/IDL exception types. Section 28.2.6 Change the first sentence to: An RMI/IDL exception type is a checked exception class (as defined by the Java Language Specification). Change the beginning of the second sentence to: Since checked exception classes extend java.lang.Throwable ... In the second paragraph, change the first bullet to: - is a checked exception class Section 28.3.5 Add to the end of the first sentence: "and conforming exception classes that are not RMI/IDL exception types". Section 28.3.4.3 Change the last bullet of Read-write properties to: - get<name> and set<name> do not throw any checked exceptions except for java.rmi.RemoteException and its subclasses, Change the last bullet of Read-only properties to: - does not throw any checked exceptions except for java.rmi.RemoteException and its subclasses, Section 28.3.4.4 Change #5 and #6 to: 5. Each declared RMI/IDL exception type (other than java.rmi.RemoteException and its subclasses) is mapped to the corresponding OMG IDL exception. 6. java.rmi.RemoteException and its subclasses, and unchecked exception classes, are assumed to be mapped to the implicit CORBA system exception, and are therefore not explicitly declared in OMG IDL. Section 28.3.5.4 Change #3 to: 3. Each declared RMI/IDL exception type (other than java.rmi.RemoteException and its subclasses) is mapped to the corresponding OMG IDL exception. 4. java.rmi.RemoteException and its subclasses, and unchecked exception classes, are not explicitly declared in OMG IDL. Section 28.3.7.1 Delete the first sentence and the IDL that immediately follows. At the beginning of the next sentence, change "Every other" to "Each". Section 28.3.7.2 In the first bullet, delete 'or "Error"'. Section 28.4.7 Change the second and third sentences to: Exceptions that are instances of (or subclasses of) RMI/IDL exception types declared by the method are marshaled as user exceptions in the usual way. All other Java exceptions are marshaled as CORBA UNKNOWN system exceptions whose GIOP Reply message includes an UnknownExceptionInfo service context containing the marshaled Java exception thrown by the server implementation.
Actions taken:
March 16, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2552: Treatment of classes with writeReplace/readResolve methods (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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?
 

Resolution:
Revised Text: Add the following text at the end of section 1.3.5.6: An RMI/IDL value type that has a writeReplace or readResolve method is mapped to an OMG IDL valuetype using the same mapping rules that apply to other RMI/IDL value types.
Actions taken:
March 19, 1999: received issue
July 30, 2007: closed issue

Discussion:
Closed, no change. See revised text below.


Issue 2565: Mapping of Java constructors to init is broken (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
March 31, 1999: received issue
May 16, 2006: closed issue

Discussion:


Issue 2804: stub classes can violate licensing and package sealing (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
 
 

Resolution:
Revised Text:
Actions taken:
July 15, 1999: received issue

Discussion:


Issue 2805: (java2idl-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
July 16, 1999: received issue

Discussion:


Issue 2806: (java2idl-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
July 16, 1999: received issue

Discussion:


Issue 2807: (java2idl-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
July 16, 1999: received issue

Discussion:


Issue 2808: (java2idl-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
July 16, 1999: received issue

Discussion:


Issue 2809: (java2idl-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
July 16, 1999: received issue

Discussion:


Issue 2810: (java2idl-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:

Resolution: closed is XMI 1.1 RTF
Revised Text:
Actions taken:
July 16, 1999: received issue
May 4, 2000: closed issue

Discussion:


Issue 2813: (java2idl-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
July 13, 1999: received issue

Discussion:


Issue 2815: (java2idl-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
July 21, 1999: received issue

Discussion:


Issue 2816: (java2idl-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:

Resolution: resolved in XMI 1.1 RTF
Revised Text:
Actions taken:
July 21, 1999: received issue
May 4, 2000: closed issue

Discussion:


Issue 2818: (java2idl-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:

Resolution: resolved in XMI 1.1 RTF
Revised Text:
Actions taken:
July 21, 1999: received issue
May 4, 2000: closed issue

Discussion:


Issue 2894: Security problem in JavaToIDL mapping (java2idl-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
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.
 

Resolution:
Revised Text:
Actions taken:
September 20, 1999: received issue

Discussion:


Issue 3093: PortableRemoteObject.narrow(null) (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
December 7, 1999: received issue
May 16, 2006: closed issue

Issue 3117: Name mangling scheme broken. (java2idl-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity:
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.

Resolution: closed, no change
Revised Text:
Actions taken:
December 15, 1999: received issue
May 24, 2001: closed issue

Discussion:
This problem occurs in two cases only:
1. The case described in the issue, where two overloaded Java methods have parameters declared as byte (a Java primitive) and
octet (a class in the default package). The method name mangling rules map both of these to "octet".
2. The case where two overloaded Java methods have parameters declared as char (a Java primitive) and wchar (a class in the
default package). The method name mangling rules map both of these to "wchar".
 
There are many other cases of valid Java method declarations that do not map to unique names in IDL. The Java to IDL mapping
was never intended to ensure uniqueness in all possible cases, but only in cases that are likely to occur in real applications. Since
this error can only occur when an application contains classes called "octet" or "wchar" in the default package, and since use of
classes in the default package is not recommended for deployment of production applications, it is not worth introducing a new
mangling rule to support these two specific cases. Instead, the rules in section 1.3.2.9 should apply in this case.
(Vijay)
I vote no on 3117 and 3670 as I am very concerned that there are is an increasing number of cases where we decide not to handle
it because it's too difficult or backward incompatible and the number of cases where the reverse mapping cannot handle a valid
java class is becoming large.


Issue 3118: Boolean attributes (java2idl-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
December 15, 1999: received issue
May 16, 2006: closed issue

Issue 3151: Stream format problem for custom marshalled RMI types (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.

Resolution: see below
Revised Text: The following example shows a case that currently doesn't work: public class A implements java.io.Serializable { // any data } public class B extends A { // any data private void writeObject(java.io.ObjectOutputStream stream) { // any code } private void readObject(java.io.ObjectInputStream stream) { // any code } } public class C extends B { // any data } At present, an instance of C is marshalled as C-header A-data B-data C-data C-endtag where all the data is written and read by the ValueHandler and is chunked according to the valuetype chunking rules. Suppose some change to the writeObject() implementation in class B causes more B-data to be written, while everything else stays the same. When the old B code unmarshals a new B instance, it will not fully consume all the B-data and this will cause the unmarshalling of the C-data to be incorrect since the stream will be out of sync. The problem is caused by a deficiency in the stream encoding for custom serialized data. In the example above, the existing format does not identify the boundary between the B-data and the C-data, so it is impossible for the unmarshalling code in the ValueHandler to skip over any extraneous B-data before it starts to read the C-data. The proposed resolution is to enclose the B-data in a nested valuetype. The repid for the nested valuetype must be specified by the Java to IDL mapping so that it can be read by IDL custom unmarshalling code in other languages. The repid is "RMI:org.omg.custom.<class>:<hashcode>:<suid>" where <class> is the fully-qualified name of the class whose writeObject method is being invoked and <hashcode> and <suid> are the class's hashcode and SUID. The other language implementation has to provide a suitable custom valuetype implementation for the nested valuetype and may have to provide a value factory that maps the standard repid to this implementation. For Java unmarshalling, the ValueHandler will understand the special repid and process its contents as RMI-IIOP custom serialized data. Since valuetype headers and end tags are written by the ORB's OutputStream and not by the ValueHandler, it will be necessary to add new APIs to the OutputStream for the ValueHandler to call when marshalling custom valuetype data. These new APIs will write the valuetype header and end tag for the nested valuetype, keep track of the valuetype nesting level, and take care of chunking for the nested valuetype. Rather than adding yet another level of OutputStream subclassing, the new APIs are defined within an interface called org.omg.CORBA.portable.ValueOutputStream which will be implemented by the output stream passed to the ValueHandler. The new interface is defined as follows: public interface ValueOutputStream { void start_value(java.lang.String rep_id); void end_value(); } When the ValueHandler encounters a class with custom serialized data, it calls the start_value() method on the output stream that it was given, passing the special custom repid for the custom-serialized class. The output stream ends the currently open chunk, writes a valuetype header for the nested custom valuetype, and increments the valuetype nesting depth. It then returns to the ValueHandler, which calls writeObject() to write the custom serialized data. When writeObject() returns, the ValueHandler calls end_value() on the stream to end the current chunk, write the end tag, and decrement the valuetype nesting depth. When unmarshalling a class with custom serialized data, the ValueHandler needs to call the ORB's input stream to consume the valuetype header and end tag. A new interface org.omg.CORBA.portable.ValueInputStream that defines the necessary APIs will be implemented by the input stream. This interface is defined as follows: public interface ValueInputStream { void start_value(); void end_value(); } The ValueHandler calls the start_value() method on the input stream. The input stream reads the nested valuetype header and increments the valuetype nesting depth, then returns to the ValueHandler. The ValueHandler reads the custom serialized data, then calls end_value() which consumes the end tag (after skipping any data that precedes the end tag) and decrements the valuetype nesting depth. For languages other than Java, the nested valuetype must be handled explicitly by calling write_Value() and read_Value() within the implementations of the marshal() and unmarshal() methods. To assist in the implementation of these methods, a new IDL valuetype is generated by the Java to IDL mapping. In the example above, this would be: module org { module omg { module customRMI { custom valuetype B {}; #pragma ID B "RMI:org.omg.customRMI.B:1234567890ABCDEF:FEDCBA0987654321" }; }; }; This would be implemented in C++ (for example) with marshal() and unmarshal() methods that read and write the appropriate data. The new stream format would be identified by a format version of 2 (currently 1). By default, ORBs that support GIOP version 1.2 are assumed to accept format version 1 only, and ORBs that support GIOP 1.3 are assumed to accept format versions 1 and 2. These defaults can be overridden by a new tagged component for servers, and by a new service context for clients. The new tagged component is identified by the following component id: const ComponentId TAG_RMI_CUSTOM_MAX_STREAM_FORMAT = xx; // number to be assigned by OMG The TAG_RMI_CUSTOM_MAX_STREAM_FORMAT component has an associated value of type octet, encoded as a CDR encapsulation, designating the maximum stream format version for RMI/IDL custom value types that can be used in GIOP messages sent to this IOR. The TAG_RMI_CUSTOM_MAX_STREAM_FORMAT component can appear at most once in any IOR profile. For profiles supporting IIOP 1.2 or greater, it is optionally present. If this component is omitted, then the default maximum stream format version for RMI/IDL custom value types sent to this IOR is 1 for IIOP 1.2 and 2 for IIOP 1.3. The new service context is identified by the following service id: const ServiceId RMICustomMaxStreamFormat = yy; // number to be assigned by OMG RMICustomMaxStreamFormat identifies a CDR encapsulation of a single octet that specifies the highest RMI/IDL custom stream format version that can be used for RMI/IDL custom valuetypes marshaled within a GIOP reply associated with the GIOP request that carries this service context.Revised Text: The following changes are proposed in the Java to IDL mapping specification, document number ptc/2001-06-15: In section 1.3.5.6, add the following at the end of the second paragraph: "An additional IDL custom valuetype in the module ::org::omg::customRMI is also generated to assist with marshaling and unmarshaling instances of the class. See section 1.3.5.8 for details." Add a new section 1.3.5.8 "Secondary custom valuetype", renumbering the existing section 1.3.5.8 and subsequent sections: "In addition to the primary mapping described above, an RMI/IDL value type containing a writeObject method is mapped to a secondary IDL custom valuetype. The module name for this valuetype is formed by taking the ::org::omg::customRMI prefix and then adding the primary mapped type’s module name. The name of the secondary valuetype is the same as the name of the primary IDL custom value type to which the RMI/IDL value type was mapped. The secondary valuetype has no inheritance, data members, methods, or initializers. It has a #pragma ID specifying a repository ID formed by taking the repository ID of the primary custom valuetype and prefixing the Java package name with "org.omg.customRMI.". The secondary custom valuetype represents the enclosure of writeObject data that is wriitten to the serialization stream when the primary custom valuetype or any of its subclasses is serialized using format version 2, as described in item 1d of section 1.4.10. For IDL custom marshaling and unmarshaling of the primary mapped IDL valuetype, the marshal() and unmarshal() methods can call write_Value() and read_Value() to write and read the nested valuetype enclosure. This will cause the marshal() and unmarshal() methods of the secondary mapped IDL valuetype to be called to write and read the custom serialized data." In existing section 1.3.5.9, add the following to the generated IDL: module org { module omg { module customRMI { module alpha { module bravo { custom valuetype Kangaroo {}; #pragma ID Kangaroo "RMI:org.omg.customRMI.alpha.bravo.Kangaroo:87654321ABCDEF01:9876543210FEDCBA" }; }; }; }; }; In section 1.4.10, replace numbered paragraphs 1 and 2 by the following: "a. octet - Format version. 1 or 2. For serializable objects with a writeObject method: b. boolean - True if defaultWriteObject was called, false otherwise. c. (optional) Data written by defaultWriteObject. The ordering of the fields is the same as the order in which they appear in the mapped IDL valuetype, and these fields are encoded exactly as they would be if the class did not have a writeObject method. 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. For externalizable objects: b. (optional) Data written by writeExternal, encoded as specified below." In the same section, at the end of subsection 1, add the following: "The default custom stream format is 1 for GIOP 1.2 and 2 for GIOP 1.3. For RMI/IDL custom value types marshaled within GIOP requests, a format version not greater than the default for the GIOP message level must be sent, except where the TAG_RMI_CUSTOM_MAX_STREAM_FORMAT tagged component (see section 1.4.11) is part of the IOR profile. For RMI/IDL custom value types marshaled within GIOP replies (including the UnknownExceptionInfo service context), a format version not greater than the default for the GIOP message level must be sent, except where the RMICustomMaxStreamFormat service context (see section 1.4.12) was sent on the associated GIOP request." Add a new section 1.4.11 "TAG_RMI_CUSTOM_MAX_STREAM_FORMAT Component", renumbering the existing section 1.4.11 and subsequent sections: "Although the IIOP level of an IOR specifies a default maximum stream format version for RMI/IDL custom value types marshaled as part of GIOP requests to this IOR, there are cases when it may be necessary to override this default. The TAG_RMI_CUSTOM_MAX_STREAM_FORMAT component has an associated value of type octet, encoded as a CDR encapsulation, designating the maximum stream format version for RMI/IDL custom value types that can be used in GIOP messages sent to this IOR. The TAG_RMI_CUSTOM_MAX_STREAM_FORMAT component can appear at most once in any IOR profile. For profiles supporting IIOP 1.2 or greater, it is optionally present. If this component is omitted, then the default maximum stream format version for RMI/IDL custom value types sent to this IOR is 1 for IIOP 1.2 and 2 for IIOP 1.3." Add a new section 1.4.12 "RMICustomMaxStreamFormat Service Context", renumbering the existing section 1.4.11 and subsequent sections: "Although the GIOP level of a request specifies a default maximum stream format version for RMI/IDL custom value types marshaled as part of the associated reply, there are cases when it may be necessary to override this default. RMICustomMaxStreamFormat identifies a CDR encapsulation of a single octet that specifies the highest RMI/IDL custom stream format version that can be used for RMI/IDL custom valuetypes marshaled within a GIOP reply associated with the GIOP request that carries this service context. If this service context is omitted from a GIOP request, then the default maximum stream format version for RMI/IDL custom value types marshaled within a GIOP reply associated with this request is 1 for GIOP 1.2 and 2 for GIOP 1.3." Change the title of existing section 1.5.1.3 to "ValueHandler and ValueHandlerMultiFormat". Also change the first paragraph to: "The interfaces javax.rmi.CORBA.ValueHandler and javax.rmi.CORBA.ValueHandlerMultiFormat define methods that allow serialization of Java objects to and from GIOP streams." Also add the following interface: //Java public interface ValueHandlerMultiFormat extends ValueHandler { byte getMaximumStreamFormatVersion(); void writeValue(org.omg.CORBA.portable.OutputStream out, java.io.Serializable value, byte streamFormatVersion); } and add the following paragraphs to this section before the "Execution Model for Serialization" subsection: "The ValueHandlerMultiFormat interface introduces a method getMaximumStreamFormatVersion that returns the maximum stream format version for RMI/IDL custom value types that is supported by this ValueHandler object. The ValueHandler object must support the returned stream format version and all lower versions. The format versions currently defined are 1 and 2. See section 1.4.10 "Custom Marshaling Format" for more details. The ValueHandlerMultiFormat interface introduces an overloaded writeValue method that allows the ORB to pass the required stream format version for RMI/IDL custom value types. If the ORB calls this method, it must pass a stream format version between 1 and the value returned by the getMaximumStreamFormatVersion method inclusive, or else a BAD_PARAM exception with standard minor code aa (note to editor: number to be assigned by OMG) must be thrown. If the ORB calls the ValueHandler.writeValue method, stream format version 1 is implied." Add new sections 1.5.1.3 "ValueOutputStream" and 1.5.1.4 "ValueInputStream", renumbering the existing section 1.5.1.3 and subsequent sections: "The interface org.omg.CORBA.portable.ValueOutputStream defines methods that allow serialization of custom-marshaled RMI/IDL objects to GIOP streams. // Java package org.omg.CORBA.portable; public interface ValueOutputStream { void start_value(java.lang.String rep_id); void end_value(); } The interface org.omg.CORBA.portable.ValueInputStream defines methods that allow deserialization of custom-marshaled RMI/IDL objects from GIOP streams. // Java package org.omg.CORBA.portable; public interface ValueInputStream { void start_value(); void end_value(); } " In existing section 1.5.1.3, add a new paragraph at the end of the "Execution Model for Serialization" section as follows: "The ORB output stream passed to the ValueHandlerMultiFormat.writeValue method must implement the ValueOutputStream interface, and the ORB input stream passed to the ValueHandler.readValue method must implement the ValueInputStream interface. For output streams, the start_value() method ends any currently open chunk, writes a valuetype header for a nested custom valuetype (with a null codebase and the specified repository ID), and increments the valuetype nesting depth. The end_value() method ends any currently open chunk, writes the end tag for the nested custom valuetype, and decrements the valuetype nesting depth. For input streams, the start_value() method reads a valuetype header for a nested custom valuetype and increments the valuetype nesting depth. The end_value() method reads the end tag for the nested custom valuetype (after skipping any data that precedes the end tag) and decrements the valuetype nesting depth." In existing section 1.5.1.3, add new paragraphs at the end of the "Value Marshaling" section as follows: "Before calling the writeValue method of the ValueHandler object, the ORB must determine the stream format version to be used. This is the maximum format version that is supported by both the local ValueHandler and the remote connection endpoint. The maximum local format version is the value returned by the getMaximumStreamFormatVersion method of the ValueHandler object, or 1 if the ValueHandler object doesn't support the ValueHandlerMultiFormat interface. The maximum remote format version is 1 for GIOP 1.2 messages and 2 for GIOP 1.3 messages, except where these default values are overridden by either the TAG_RMI_CUSTOM_MAX_STREAM_FORMAT tagged component (see section 1.4.11) or the RMICustomMaxStreamFormat service context (see section 1.4.12). For GIOP 1.2 messages, recognition of these overrides is optional. If the stream format version computed in this way is 2 or greater, the ORB must call the ValueHandlerMultiFormat.writeValue method, passing this value. If the stream format version computed in this way is 1, the ORB may call either the ValueHandlerMultiFormat.writeValue method (with stream format 1) or the ValueHandler.writeValue method. If the ORB's call to the ValueHandler object's writeValue method specified RMI/IDL custom value type stream format version 2, then the ValueHandler object must call the ValueOutputStream.start_value() and ValueOutputStream.end_value() methods of the ORB stream before and after writing the data specified by item 1d of section 1.4.10. The rep_id string passed to the start_value() method must be "RMI:org.omg.custom.<class>:<hashcode>:<suid>" where <class> is the fully-qualified name of the class whose writeObject method is being invoked and <hashcode> and <suid> are the class's hashcode and SUID. For format version 2, if the ORB stream passed to the ValueHandler doesn't support the ValueOutputStream interface, then a BAD_PARAM exception with standard minor code bb (note to editor: number to be assigned by OMG) must be thrown." In existing section 1.5.1.3, add a new paragraph at the end of the "Value Unmarshaling" section as follows: "If the RMI/IDL custom data unmarshaled from the input stream was encoded using stream format 2, then the ValueHandler object must call the ValueInputStream.start_value() and ValueInputStream.end_value() methods of the ORB stream before and after reading the data specified by item 1d of section 1.4.10. For format version 2, if the ORB stream passed to the ValueHandler doesn't support the ValueInputStream interface, then a BAD_PARAM exception with standard minor code cc (note to editor: number to be assigned by OMG) must be thrown. If the format version unmarshaled by the ValueHandler is greater than the maximum version that it supports, then a MARSHAL exception with standard minor code dd (note to editor: number to be assigned by OMG) must be thrown." The following changes are proposed in the CORBA specification, document number formal/2001-09-34: In section 4.11.4, add the following exception standard minor codes: BAD_PARAM aa (note to editor: number to be assigned by OMG) Unsupported RMI/IDL custom value type stream format. BAD_PARAM bb (note to editor: number to be assigned by OMG) ORB output stream does not support ValueOutputStream interface. BAD_PARAM cc (note to editor: number to be assigned by OMG) ORB input stream does not support ValueInputStream interface. MARSHAL dd (note to editor: number to be assigned by OMG) Unsupported RMI/IDL custom value type stream format. In section 13.6.6, add the following ComponentId constant definition to the first list: const ComponentId TAG_RMI_CUSTOM_MAX_STREAM_FORMAT = xx; // number to be assigned by OMG In section 13.6.6.3, add the following bullet: TAG_RMI_CUSTOM_MAX_STREAM_FORMAT - See the Java to IDL mapping specification (formal/xx-xx-xx), section 1.4.11 "TAG_RMI_CUSTOM_MAX_STREAM_FORMAT Component". In section 13.7.1, add the following ServiceId constant definition: const ServiceId RMICustomMaxStreamFormat = yy; // number to be assigned by OMG and the following bullet: RMICustomStreamFormat identifies a CDR encapsulation of a single octet as described in the Java to IDL mapping specification (formal/xx-xx-xx), section 1.4.12 "RMICustomMaxStreamFormat Service Context". In section 13.9, add a row to the table for feature "RMICustomStreamFormat service context" showing that it is optional for version 1.2 and mandatory for GIOP 1.3 (when the 1.3 column is added). In section A.2, add a row to the table for ServiceId tag value RMICustomMaxStreamFormat indicating that it is described in the Java to IDL mapping specification (formal/xx-xx-xx), section 1.4.12 "RMICustomMaxStreamFormat Service Context". In section A.3, add a row to the table for ComponentId tag value TAG_RMI_CUSTOM_MAX_STREAM_FORMAT indicating that it is described in the Java to IDL mapping specification (formal/xx-xx-xx), section 1.4.11 "TAG_RMI_CUSTOM_MAX_STREAM_FORMAT Component".
Actions taken:
December 20, 1999: received issue
May 13, 2002: closed issue

Issue 3152: Tie.deactivate() exception handling (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.)

Resolution: See revised text below.
Revised Text: 1. In section 1.5.1.1, add "throws java.rmi.NoSuchObjectException" to the declaration of the Tie.deactivate method. 2. In section 1.5.1.1, add the following sentence at the end of the paragraph describing the Tie.deactivate method: "If the target object could not be deactivated (e.g., because it is not currently active), a NoSuchObjectException is thrown." 3. In section 1.5.1.4, add "throws java.rmi.NoSuchObjectException" to the declaration of the Util.unexportObject method. 4. In section 1.5.1.4, add the following sentence at the end of the paragraph describing the Util.unexportObject method: "If the object is not currently exported or could not be deactivated, a NoSuchObjectException is thrown." 5. In section 1.5.3.2, add "throws java.rmi.NoSuchObjectException" to the declaration of the UtilDelegate.unexportObject method.
Actions taken:
December 21, 1999: received issue
May 24, 2001: closed issue

Discussion:
The lack of a throws clause on the signature for Tie.deactivate() was an oversight. This method is called only by
Util.unexportObject(), which is called only by PortableRemoteObject.unexportObject(). Since the signature for
PortableRemoteObject.unexportObject() has a throws clause for java.rmi.NoSuchObjectException, the same throws clause should
be added to the signatures for both Tie.deactivate() and Util.unexportObject(). If a POA-based tie gets a POA exception when
deactivating an object, it should throw a NoSuchObjectException whose detail field contains the original POA exception.
Util.unexportObject() should rethrow this exception to PortableRemoteObject.unexportObject(), which should rethrow it to its
caller.


Issue 3160: Definition of serialVersionUID field (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
December 22, 1999: received issue
May 16, 2006: closed issue

Issue 3200: Container/member name clashes (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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:

Resolution:
Revised Text:
Actions taken:
January 9, 2000: received issue
May 16, 2006: closed issue

Issue 3433: No factory for javax.rmi.ClassDesc (java2idl-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity:
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.

Resolution: See revised text below
Revised Text: 1. In section 1.3.5.11, change the declarations of repid and codebase from private to public. 2. Add the following field to section 1.3.5.11: static final long serialVersionUID = -3477057297839810709L;
Actions taken:
March 20, 2000: received issue
May 24, 2001: closed issue

Discussion:
It is not correct to say that non-default ValueHandlers must construct a ClassDesc instance, since the correct wire representation
can be written without an actual instance being constructed. However, it seems reasonable to modify the definition of the
ClassDesc class to allow instances to be constructed and initialized. The simplest way to do this is by making the data members
public instead of private. This also has the benefit of making these data members accessible from other languages, by making
them public in the Java to IDL mapping of this class. 
Note that changing these member declarations to public changes the default SUID. Therefore, for on-the-wire compatibility with
current implementations, it is necessary to specify the current SUID value using an explicit declaration.


Issue 3590: loader.loadClass() or Class.forName()? (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Bob Scheifler, rws(at)east.sun.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: See revised text below.
Revised Text: n 1.4.9.5, replace #4 of the Java 2 case by: 4. If a class was not successfully loaded by step 1, 2, or 3, and loader is non-null, then call Class.forName(className, false, loader).
Actions taken:
May 2, 2000: received issue
May 24, 2001: closed issue

Issue 3641: Java to IDL mapping contradictive to CORBA/IIOP 2.3.1 (java2idl-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
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

Resolution: Close, no change. Core RTF issue 4785 has added exceptions to IDL valuetype initializers, which reso
Revised Text:
Actions taken:
May 24, 2000: received issue
May 13, 2002: closed issue

Discussion:
This issue could be resolved by adding exceptions to initializers in the CORBA core spec. However, the core RTF recently voted to close issue 3781 with no change because they considered adding exceptions to initializers to be out of scope for an RTF since it is not a bug fix. Also, it is very dificult to do this without causing incompatibilities in the IR interfaces in the CORBA module that deal with initializers. However, the Components RFP is adding an ExtendedIR module to accommodate the IR changes needed for CCM, and it is possible that the Java to IDL RTF could work with the Components FTF to add exceptions on initializers in the ExtendedIR module as part of CORBA 3.0 (though this change is not motivated by a components issue). One problem with this approach is that adding exceptions on initializers in CORBA 3.0 does not resolve the current broken state of the Java to IDL mapping in this area for CORBA 2.x. 
 
Before taking this issue any further with other RTFs or FTFs I would like to know if the Java to IDL RTF wants to pursue getting exceptions on initializers added to the core spec. Please indicate your preferred course of action by voting for either option A or option B below.
A. Replace numbered paragraphs 3 and 4 in section 1.3.5.4 of the Java to IDL mapping spec by the following text:
3. Java exceptions are not mapped to IDL.
B. Leave this issue open for now and work with other RTFs or FTFs to attempt to get the core spec changed to add exceptions to IDL initializers.


Issue 3670: Exception mapping needs fixing (java2idl-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity:
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?

Resolution: See revised text below
Revised Text: Add the following after the bullets in section 1.3.7.2: "If applying the above rules yields the same OMG IDL name for more than one Java exception name (e.g., there are Java exception names foo and fooException, which both map to the OMG IDL name fooEx), then this is treated as an error."
Actions taken:
June 1, 2000: received issue
May 24, 2001: closed issue

Discussion:
There is no conflict between fooError and the exception class names foo and fooException, since a trailing Error string is not
removed before appending the Ex suffix. However, there is a conflict between foo and fooException. 
Without making an incompatible change, there is no way to resolve this conflict, since the mapping of each class must be
deterministic and cannot vary depending on whether another exception class with this name conflict also exists (since the second
class could be created after the first class has been mapped). 
This is similar to the treatment of Java class or interface names that differ only in case. The mapping deals with such method or
field names within a class by applying a deterministic mangling rule, since all method and field names within a class are known
when the class is mapped. However, applying the same mangling to class or interface names would require global knowledge of
all class and interface names that could be mapped, which is not practical. 
It seems reasonable to follow this precedent and not specify a mangling fpr conflicting exception names that would require global
knowledge of all class and interface names that could be mapped. 
In practice this conflict is unlikely to cause any serious problems, since the JDK names all exceptions with an Exception suffix and
other packages should use a a consistent naming convention for all their exceptions (either with or without an Exception suffix). 
(Vijay)
I vote no on 3117 and 3670 as I am very concerned that there are is an increasing number of cases where we decide not to handle
it because it's too difficult or backward incompatible and the number of cases where the reverse mapping cannot handle a valid
java class is becoming large.


Issue 3754: Java reverse mapping local case cannot properly support Portable Intercepto (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., nobody)
Nature: Uncategorized Issue
Severity:
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(x)
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(x);
		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. 

Resolution: see below
Revised Text: Resolution: Closed, accepted. This issue corresponds to issue 4701 in the IDL to Java RTF, and this proposed resolution is intended to be consistent with the resolution to that issue. See revised text below. Revised Text: 1. In section 1.5.2.2, replace steps 3 and 4 by the following, and renumber step 5 to step 4. 3. If _servant_preinvoke returned a non-null ServantObject so, do the following: a. Call ((Aardvark)so.servant).echo(x) b. If the invocation on the servant completed without throwing an exception, and so is an instance of ServantObjectExt, then call so.normalCompletion(). c. If the invocation on the servant threw exception exc, and so is an instance of ServantObjectExt, then call so.exceptionalCompletion(exc). d. Call this._servant_postinvoke(so) 2. In the sample code in section 1.5.2.2, replace the following code: try { return ((Aardvark)so.servant).echo(x); } catch (Throwable ex) { Throwable ex2 = (Throwable) by the following: try { int result = ((Aardvark)so.servant).echo(x); if (so instanceof ServantObjectExt) ((ServantObjectExt)so).normalCompletion() ; return result; } catch (Throwable ex) { if (so instanceof ServantObjectExt) ((ServantObjectExt)so).exceptionalCompletion(ex); Throwable ex2 = (Throwable)
Actions taken:
July 21, 2000: received issue
July 26, 2000: moved to the IDL-Java RTF
December 18, 2001: moved back to Java to IDL RTF
May 13, 2002: closed issue

Discussion:
This issue is clearly about the Java to IDL mapping, so it belongs in the Java to IDL RTF, which is where is was originally. However, it was reassigned to this RTF I think largely because the solution requires changes to the org.omg.CORBA.portable APIs, which belong to the Java RTF. I have created issue 4701 to cover the Java mapping issues and the changes to the portable APIs. This issue should be re-assigned back to the Java to IDL RTF.


Issue 3798: ValueHandler Interface (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity:
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.

Resolution: Remove method implementations from the definition of the ValueHandler interface.
Revised Text:
Actions taken:
August 31, 2000: received issue
May 24, 2001: closed issue

Issue 3857: Descriptions of readAny and writeAny not precise enough (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.

Resolution: See revised text below.
Revised Text: Replace the second 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_abstract_interface, the repository ID is "IDL:omg.org/CORBA/AbstractBase:1.0", the name string is "", and the any's value is a null abstract interface type (encoded as a boolean discriminant of false followed by a long value of 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, tk_objref, and tk_abstract_interface. For each of these types, both null and non-null values are valid. If the TypeCode is anything other than these, a MARSHAL exception is thrown."
Actions taken:
September 5, 2000: received issue
May 24, 2001: closed issue

Discussion:
Using tk_value for java.lang.Object null seems incorrect because a java.lang.Object does not only contain valuetypes. Another
alternative is tk_null, but this is currently used for an any with no contents rather than an any containing a null. 
The bext compromise appears to be tk_abstract_interface. The IDL abstract interface type can represent all the legal values of
java.lang.Object in the Java to IDL mapping. Also, using this representation is consistent with the folllowing usability goals: 
1. When nulls are sent from IDL to RMI-IIOP, the same insertion operations for anys that are used for non-null values should
work for null values as well. This means that all the following anys when received by RMI-IIOP as the value of a java.lang.Object
should be unmarshalled as null: 

  tk_value+null

  tk_value_box+null

  tk_objref+nil

  tk_abstract_interface+null




2. When nulls are sent from RMI-IIOP to IDL, the encoding of null sent by RMI-IIOP should be extractable using the same
extraction operations that would be used for non-null values. For example, in the IDL-to-Java mapping, both the following should
work on null values sent by RMI-IIOP: 

  myValue = myAny.extract_Value();

  myObjRef = myAny.extract_Object();




So, if we say that tk_abstract_interface is the correct RMI-IIOP encoding for a null, then both extract_Value() and
extract_Object() should be able to handle a null tk_abstract_interface type in the any. The same should be true for other
languages. 
 
Note 1: it is not clear from either the Java language binding spec or the C++ language binding spec whether a value (not just a null
value) that was inserted using a tk_abstract_interface TypeCode can be extracted using the normal extract operations for
valuetype or object reference. If this does work (and there is good reason to think it should), then this would automatically take
care of handling a null encoded as tk_abstract_interface. 
 
Note 2: Issues like the one described in Note 1 above should not be up to all the language mapping RTFs to resolve. The core
should define semantics for anys that the language bindings are required to support. 
 
Note: (For information only) I have raised a separate issue in the IDL-to-Java RTF proposing that a value (including a null value)
that was inserted into an any using a tk_abstract_interface TypeCode should be extractable using the normal extract operations
for valuetype or object reference. If this passes, I will raise a similar issue in the C++ RTF


Issue 3858: Package for PortableRemoteObjectDelegate (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.

Resolution: See revised text below
Revised Text: Add the line package javax.rmi.CORBA; to section 1.5.3.3.
Actions taken:
September 5, 2000: received issue
May 24, 2001: closed issue

Discussion:
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.


Issue 3969: Mapping of CORBA any and TypeCode (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.

Resolution: See revised text below.
Revised Text: Add the following to the end of section 1.3.9: The IDLEntity types org.omg.CORBA.Any and org.omg.CORBA.TypeCode are mapped as follows: module org { module omg { module boxedIDL { module CORBA { valuetype _Any any; #pragma ID _Any “RMI:org.omg.CORBA.Any:0000000000000000” }; }; }; }; module org { module omg { module boxedIDL { module CORBA { valuetype _TypeCode ::CORBA::TypeCode; #pragma ID _TypeCode “RMI:org.omg.CORBA.TypeCode:0000000000000000” }; }; }; };
Actions taken:
October 18, 2000: received issue
May 24, 2001: closed issue

Discussion:
This resolution is being voted a second time with a minor change. The original resolution (which passed) named the mapped IDL
type as ::org::omg::boxedIDL::CORBA::_any. The amended resolution names the type as ::org::omg::boxedIDL::CORBA::_Any.
This is the only change to the original resolution. 
 
The following points are in favor of mapping org.omg.CORBA.Any and org.omg.CORBA.TypeCode to boxed IDL types: 
1. It is more consistent with the current spec, which says that all IDLEntity types are boxed, except for certain specified cases. 
2. It supports sharing semantics when passing multiple references to the same Java Any or TypeCode object across RMI-IIOP,
just like other IDLEntity and serializable objects. 

If these are mapped to boxed types, then we need to specify the repids for the boxed valuetype encoding. These would not be
derived from the Java implementation classes as they are for other IDLEntity types (e.g., RMI:com.acme.AnyImpl:hhh:sss) since
using implementation names would not be interoperable. It would seem reasonable to use 
  RMI:org.omg.CORBA.Any:0000000000000000 and 
  RMI:org.omg.CORBA.TypeCode:0000000000000000 
as the repids.


Issue 4004: Mapping CORBA minor codes to Java (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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”

Resolution: See revised text below.
Revised Text: 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”
Actions taken:
October 30, 2000: received issue
May 24, 2001: closed issue

Issue 4058: Mapping of Java byte constants to IDL (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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."

Resolution: resolved, see below
Revised Text: In document ptc/00-12-03, 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."
Actions taken:
November 16, 2000: received issue
October 3, 2001: closed issue

Issue 4296: javax.rmi.CORBA.Util.isLocal RemoteException condition(s) not specified (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., nobody)
Nature: Uncategorized Issue
Severity:
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.

Resolution: See revised text below
Revised Text: In document ptc/00-12-03 section 1.5.1.4, change "The isLocal method has the same semantics as the ObjectImpl._is_local method, except that it can throw a RemoteException." to: "The isLocal method has the same semantics as the ObjectImpl._is_local method, except that instead of throwing an org.omg.CORBA.SystemException, it throws a java.rmi.RemoteException that is the result of passing the SystemException to the mapSystemException method."
Actions taken:
May 8, 2001: received issue
October 3, 2001: closed issue

Issue 4319: Behavior of Java writeUTF/readUTF (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Everett Anderson, )
Nature: Uncategorized Issue
Severity: Critical
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.

Resolution: See revised text below
Revised Text: In document ptc/00-12-03, replace the second last paragraph of section 1.4.10 as follows. Replace the existing text: Primitive Java types are marshaled as their corresponding IDL primitives (see Section 1.3.3, "Mappings for Primitive Types," on page 1-10). 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). by the new text: Primitive Java types are marshaled as their corresponding IDL primitives (see Section 1.3.3, “Mappings for Primitive Types,” on page 1-10). Java strings written by the java.io.ObjectOutputStream.writeUTF() method and read by the java.io.ObjectInputStream.readUTF() method are marshaled as IDL wstrings. 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).
Actions taken:
May 21, 2001: received issue
October 3, 2001: closed issue

Issue 4429: Issue with using the local stub with for example an EJB application (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity: Critical
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(); 


Resolution: Closed, accepted. See revised text below.
Revised Text: section 1.5.2.2, replace the first paragraph after the numbered list by the following: The _servant_preinvoke method returns non-null if, and only if, an optimized local call may be used. It performs any security checking that may be necessary. If the _servant_preinvoke method returns non-null, then the servant field of the returned ServantObject must contain an object that implements the RMI/IDL remote interface and can be used to call the servant implementation.
Actions taken:
July 25, 2001: received issue
May 13, 2002: closed issue

Discussion:


Issue 4497: Mapping subclasses of custom-marshaled Java classes to IDL (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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, ...

Resolution: Closed, accepted. See revised text below
Revised Text: 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, ...
Actions taken:
August 15, 2001: received issue
May 13, 2002: closed issue

Discussion:
.


Issue 4591: New issue: Behavior of writeByte, writeChar, writeBytes, writeChars (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Everett Anderson, )
Nature: Uncategorized Issue
Severity:
Summary:
A Serializable or Externalizable can define methods which take
java.io.ObjectOutputStreams.  There are four methods on that class
that are well defined in Java, but the mapping to CORBA may need to be
clarified:

writeByte(int)
writeChar(int)
writeBytes(String)
writeChars(String)

Please see the Java docs for these methods:

http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeByte(int)
http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeChar(int)
http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeBytes(java.lang.String)
http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeChars(java.lang.String)

Based on those detailed definitions, I'd say the mapping would be:

writeByte(int)
* write_octet of the lower 8 bits of the int

writeChar(int) 
* two write_octet calls in the order as shown in the java docs

writeBytes(String) 
* For each char in the String, call charAt, take the lower 8 bits, and
call write_octet

writeChars(String)
* For each char in the String, call charAt, split the char into two
bytes, and make two write_octet calls in the order shown in the java
docs

Another interpretation might be to use wstrings or wchar arrays for
writeChars.  The problem I see there is that since there isn't a
readChars method, the user will be using the DataInput methods
readFully or multiple readChar calls to reconstruct the String.  Since
the wire format of wstrings/wchars depends on the code set, he might
start to see code set specific bytes instead of the expected bytes
detailed in the java docs of writeChars and writeChar.

Resolution: see below
Revised Text: In the second last paragraph of section 1.4.10, add the following text before the last sentence of the paragraph: "Java ints and strings written by the writeByte, writeChar, writeBytes, and writeChars methods of java.io.ObjectOutputStream are marshaled as specified by the definitions of these methods in the java.io.DataOutput interface."
Actions taken:
October 4, 2001: received issue
May 13, 2002: closed issue

Discussion:
As proposed in the issue summary, the stream data written by these APIs for RMI-IIOP needs to be consistent with Java serialization, since otherwise some classes that serialize and deserialize correctly using Java serialization or RMI-JRMP would not serialize and deserialize correctly using RMI-IIOP. 

However, care needs to be taken when making this change to avoid breaking existing applications. This is because 
the revised specification for writeBytes(String) is incompatible with the way this method is currently implemented by certain JDK ORBs (specifically IBM's J2SE 1.3 and Sun's J2SE 1.3), and 
the change may affect application code as well as the ORB. 
The incompatibility is that the writeBytes() method currently converts characters to bytes using the platform's default character encoding, but the new specification doesn't do this. Therefore, any platform whose default character encoding is not ISO8859-1 (e.g., IBM zOS) will send different data for writeBytes() with the revised specification, and any application-defined Java readObject() methods that consume this data (on any platform) will have to be modified to consume unconverted data instead of converted data. Similarly, IDL custom valuetype unmarshal method implementations that consume data written by writeBytes() may have to be modified in the same way. 

Following established principles for incompatible changes to the J2SE platform, this change should only be made with adequate warning and on a major release boundary of the J2SE platform (e.g, 1.4 or 1.5) rather than on a minor release boundary (e.g., 1.4.x) or a service update (e.g., 1.4.0_xx).


Issue 4656: Mapping of ExceptionDetailMessage service context (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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, ..."

Resolution: see above
Revised Text:
Actions taken:
November 1, 2001: received issue
May 13, 2002: closed issue

Discussion:
Resolution: 
Close, no change. The proposed change would cause more problems than it solves. This is because the getMessage() method of RemoteException returns its own detail message concatenated with the detail message of its nested exception. So copying the nested exception's detail message into the top-level RemoteException will cause the same message to be printed twice, which is not very useful!


Issue 4690: There is a typo on page 1-46. (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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 !

Resolution: Closed, accepted. See revised text below
Revised Text: Change java.rmi.RuntimeException to java.lang.RuntimeException
Actions taken:
November 8, 2001: received issue
May 13, 2002: closed issue

Discussion:
.


Issue 4698: mapSystemException server mapping (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.

Resolution: Closed, accepted. See revised text below
Revised Text: 1. Change the title of section 1.4.7 from: Mapping RMI Exceptions to CORBA System Exceptions to: Mapping RMI Exceptions to CORBA Exceptions 2. In section 1.4.7, replace the following sentence: Exceptions that are instances of (or subclasses of) RMI/IDL exception types declared by the method are marshaled as user exceptions in the usual way. by the following text: Any exception that is an instance of an RMI/IDL exception type declared by the method or any subclass of these type (other than java.rmi.RemoteException and its subclasses) is marshaled as the mapped IDL exception corresponding to the declared RMI/IDL exception (see section 1.3.7.2) containing a mapped IDL valuetype corresponding to the actual runtime RMI/IDL exception type (see section 1.3.7.1). On the client side, the mapped IDL valuetype is unmarshaled and thrown back to the application. For example, if a method in an RMI/IDL remote interface declares an exception type MammalException and its implementation throws an instance of WombatException (a subclass of MammalException), then this exception is marshaled as an IDL exception MammalEx containing an IDL valuetype WombatException, and a WombatException is thrown to the client application. 3. In the table in section 1.4.8.1, change java.lang.Error to java.lang.Error (or subclass) java.rmi.RemoteException to java.rmi.RemoteException (or subclass) java.lang.RuntimeException to java.lang.RuntimeException (or subclass)
Actions taken:
November 11, 2001: received issue
May 13, 2002: closed issue

Issue 4795: RMI-IIOP interop bet. J2SE 1.3 and 1.4 (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Everett Anderson, )
Nature: Uncategorized Issue
Severity: Critical
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.

Resolution: see below
Revised Text: Add a new paragraph at the end of section 1.4.7 of the Java to IDL mapping specification, as follows: "In order to support versioning of the Java exception marshaled within an UnknownExceptionInfo service context, a SendingContextRunTime service context must previously have been processed for the connection. If a GIOP message carrying both an UnknownExceptionInfo service context and a SendingContextRunTime service context is received, and no SendingContextRunTime service context has previously been processed for this connection, then the SendingContextRunTime service context must be processed before the data within the UnknownExceptionInfo service context is unmarshaled."
Actions taken:
December 19, 2001: received issue
May 13, 2002: closed issue

Discussion:
Resolution: 
In order to make progress on issue 4795, the proposal is that we split it into two parts:
a) the immediate need to fix an interoperability problem between JDK 1.3 and JDK 1.4 when certain exceptions are thrown
b) the desire expressed by many RTF members and others to allow full type information to be sent with valuetypes, so that callbacks to the SendingContextRunTime aren't needed for versioning 

This split would allow us to do a fix for part a) in this RTF to close this issue and allow JDK 1.3 to talk to JDK 1.4 correctly, and raise a new issue for part b) to be resolved by the next RTF. The fix for part b) could be part of a new GIOP level and might involve fairly significant CDR changes. 

The proposed resolution to part a) is to require that the SendingContextRunTime service context be processed before the UnknownExceptionInfo service context. If the UnknownExceptionInfo service context happens to physically precede the SendingContextRunTime service context on the wire, and no SendingContextRunTime service context had previously been processed for the connection, then the UnknownExceptionInfo service context would have to be copied to a temporary buffer and its data unmarshalled after the SendingContextRunTime service context has been processed. This should be quite easy to implement, and could be retrofitted to JDK 1.3 in a service update. 

Adopting this resolution for the immediate problem would not preclude making a further change later to add optional type information to CDR valuetypes so that the need for a callback could be eliminated.


Issue 5330: Stream encoding for omitted optional custom data (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.

Resolution: Closed, accepted. See proposed revised text below
Revised Text: 1. 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. 2. At the end of the Value Unmarshaling section (1.5.1.5), add the following: "When using stream version 2, the ORB input stream must throw a MARSHAL exception with minor code [nn] to signal an incompatibility between the custom data on the wire and read operations from the ValueHandler until end_value is called. This can occur when a sender's version of a class does not write custom data, but the receiver's version attempts to perform a read operation."
Actions taken:
May 29, 2002: received issue
December 11, 2002: closed issue

Issue 5332: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Everett Anderson, )
Nature: Uncategorized Issue
Severity:
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;


    ...
}

Resolution: Closed, accepted. See proposed revised text below
Revised Text: 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; ... }
Actions taken:
June 3, 2002: received issue
December 11, 2002: closed issue

Discussion:
.


Issue 5454: Java Codebase tagged component and POA (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Everett Anderson, )
Nature: Uncategorized Issue
Severity:
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;
};

Resolution: see above
Revised Text: 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 must be used in this POA's IORs. The any passed to ORB::create_policy must 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; };
Actions taken:
July 9, 2002: received issue
July 1, 2003: closed issue

Discussion:
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;
};


Issue 5723: Issue with ValueHandler.getRunTimeCodeBase and PRO.exportObject (java2idl-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Cuie Zhao, nobody)
Nature: Uncategorized Issue
Severity:
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? 

Resolution: Closed, accepted. See revised text below
Revised Text: 1. Add a new section 1.4.14 "Creating ORB Instances" as follows, renumbering existing section 1.4.14 to 1.4.15. "The Portability APIs (see section 1.5) and Application Programming Interfaces (see section 1.6) in the java.rmi.CORBA package define functionality that is not part of the ORB and requires the use of an existing ORB instance for certain operations. Nothing in this specification requires an implementation of these javax.rmi.CORBA APIs to create a new ORB instance." 2. In section 1.5.1.5, change the title to "ValueHandler and Related Interfaces". 3. In section 1.5.1.5, first paragraph, change javax.rmi.CORBA.ValueHandler and javax.rmi.CORBA.ValueHandlerMultiFormat to javax.rmi.CORBA.ValueHandler, javax.rmi.CORBA.ValueHandlerMultiFormat, and javax.rmi.CORBA.ValueHandlerCodeBaseDelegate 4. In section 1.5.1.5, mark the getRunTimeCodeBase method with the @deprecated javadoc tag. 5. In section 1.5.1.5, add the following declaration: public interface ValueHandlerCodeBaseDelegate { org.omg.SendingContext.CodeBaseOperations getRunTimeCodeBaseDelegate(); } 6. In section 1.5.1.5, add the following paragraph immediately before the subheading "Execution model for Serialization": "The valueHandlerCodeBaseDelegate interface introduces a method getRunTimeCodeBaseDelegate. This method returns an implementation delegate that an ORB can use to create a SendingContext::RunTime object reference and a SendingContextRunTime service context. This method replaces the ValueHandler.getRunTimeCodeBase method, which is deprecated. The ValueHandler object returned by the Util.createValueHandler method must also implement the ValueHandlerCodeBaseDelegate interface." 7. In section 1.5.1.5, subsection "Value Marshaling", third paragraph, change the first sentence from "The ORB obtains the SendingContextRunTime service context from the ValueHandler object by calling the ValueHandler.getRunTimeCodeBase method." to "The ORB casts the ValueHandler object to type ValueHandlerCodeBaseDelegate and calls its getRunTimeCodeBaseDelegate method to obtain an implementation delegate of type CodeBaseOperations. The ORB creates a SendingContextRunTime service context containing an object reference for a tied implementation whose delegate is this CodeBaseOperations object." 8. In section 1.5.1.6, change the sentence "The createValueHandler method returns a singleton instance of a class that implements the ValueHandler interface." to "The createValueHandler method returns a singleton instance of a class that implements the ValueHandler and ValueHandlerCodeBaseDelegate interfaces."
Actions taken:
October 25, 2002: received issue
July 1, 2003: closed issue

Issue 5741: 1.2.3 RMI/IDL Remote Interfaces 2 (java2idl-rtf)

Click
here for this issue's archive.
Source: Boeing (Mr. Paul Murray, Paul.Murray3(at)PSS.Boeing.com)
Nature: Revision
Severity: Minor
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?

Resolution: see above
Revised Text:
Actions taken:
October 31, 2002: received issue
July 1, 2003: closed issue

Discussion:
Resolution: Closed, no change. 
The spec wording is correct and consistent with the RMI spec. If a method of an interface declares a superclass of RemoteException (e.g., IOException) but does not declare RemoteException, then the method can throw RemoteException and all of its subclasses, as well as some other exceptions. The method therefore meets the criteria for a conforming remote interface. 

However, if the method declares a subclass of RemoteException (e.g., ConnectException) but does not declare RemoteException, then the method cannot throw RemoteException and neither can it throw other subclasses of RemoteException, such as ConnectIOException. The method therefore fails the criteria for a conforming remote interface.



Issue 5742: scheme for mapping names is pretty byzantine (java2idl-rtf)

Click
here for this issue's archive.
Source: Boeing (Mr. Paul Murray, Paul.Murray3(at)PSS.Boeing.com)
Nature: Enhancement
Severity: Minor
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. 

Resolution: see above
Revised Text:
Actions taken:
October 31, 2002: received issue
July 1, 2003: closed issue

Discussion:
Resolution: Closed, no change. 
The current spec does cause collisions, and this has been known from the outset. The design objective was to avoid collisions for normal usage of Java method and variable names, while preserving reasonable usability for IDL generated from real-world Java classes and interfaces. 

It is correct that having names _fred and J_fred within the same Java interface or class causes problems. But how many real-world Java programs do this? Is there a problem with a real Java class or interface, or is this issue based on the theoretical possibility of a clash in a contrived case? 

Some of these suggestions have merit, but at this point it is not practical to make radical changes that would affect all RMI-IIOP applications and implementations. If there is a specific example of a name clash that is causing real-world problems, then the RTF can consider making minor changes to the existing mapping to resolve these problems


Issue 5772: Name mapping rules for non-ASCII characters (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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".


Resolution: In section 1.3.2.4, change "outside of ISO Latin 1" to "outside of ASCII".
Revised Text: In section 1.3.2.4, change "outside of ISO Latin 1" to "outside of ASCII".
Actions taken:
November 29, 2002: received issue
July 1, 2003: closed issue

Discussion:


Issue 5853: ORB shutdown should be configurable (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
February 7, 2003: received issue

Issue 5879: Custom Marshaling Format Clarification (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
March 7, 2003: received issue

Issue 5891: Guidance on RepositoryIDs for primitive types (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity:
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?

Resolution:
Revised Text:
Actions taken:
March 18, 2003: received issue

Issue 5991: Request clarification on copyObject(s) semantics (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text: In section 1.5.1.6, paragraph starting "The copyObject and ...", change the last sentence to: For non-immutable parameters, results and exceptions (including remote objects), stubs must either call these methods or generate inline code to provide equivalent semantics. In section 1.5.2.2, after the following paragraph: Local stubs are responsible for performing copying of method parameters, results and exceptions, and handling remote objects correctly in order to provide remote/local transparent RMI/IDL semantics. add the following: Local stubs are not required to copy immutable objects.
Actions taken:
July 7, 2003: received issue
July 30, 2007: closed issue

Discussion:
Resolution:
Closed, accepted. The spec already states clearly in section 1.5.1.6 that these methods do make physical copies. Clarify the spec to say that if the stub wants to optimize out the copying (which is legal), then it should omit calls to these methods. See revised text below.


Issue 6410: Custom marshalled abstract interfaces and Java/IDL (java2idl-rtf)

Source: Oracle (Dr. Andrew Piper,
andyp(at)bea.com)
Nature: Clarification
Severity:
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.

Resolution:
Revised Text: In section 1.4.10, paragraph starting "Primitive Java types ...", change last sentence to: Other Java objects are marshaled in the form of 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. [footnote: This marshaling format happens to be the same as that used for OMG IDL abstract interface types. Despite this similarity, these objects are not mapped to OMG IDL abstract interface types and they should not be treated as abstract interface types when they are unmarshaled.]
Actions taken:
November 3, 2003: received issue
July 30, 2007: closed issue

Discussion:
Resolution: Closed, no change. See revised text below.


Issue 6411: Custom marshalled abstract interfaces and Java/IDL (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity:
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

Resolution:
Revised Text:
Actions taken:
November 3, 2003: received issue
July 30, 2007: closed issue

Discussion:
Closed as duplicate of issue 6410.


Issue 6992: defaultWriteObject clarification (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Clarification
Severity:
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

Resolution:
Revised Text: In section 1.4.10, change the text quoted above to: For serializable objects with a writeObject method: b. boolean - True if defaultWriteObject or writeFields was called, false otherwise.
Actions taken:
February 17, 2004: received issue
July 30, 2007: closed issue

Discussion:
Closed, accepted. See revised text below.


Issue 7217: Mapping CORBA activity exceptions to Java (java2idl-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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

Resolution:
Revised Text: 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
Actions taken:
April 2, 2004: received issue
July 30, 2007: closed issue

Discussion:
Closed, accepted. See revised text below


Issue 7595: No wire format defined for java.lang.reflect.Proxy classes (java2idl-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
July 20, 2004: received issue

Issue 10336: Section: 1.3, Page: 1-21 (java2idl-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity: Critical
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" }; }; }; 

Resolution:
Revised Text: In section 1.3.5: ----------------- Change ... and java.lang.Class (see Section 1.3.5.12, “Mapping for java.lang.Class,” on page 1-21). to ..., java.lang.Class (see Section 1.3.5.12, “Mapping for java.lang.Class,” on page 1-21), java.lang.Enum (see Section 1.3.5.13, “Mapping for java.lang.Enum,” on page 1-xx), and all Java enum types (see Section 1.3.5.14, “Mapping for Java enum types,” on page 1-xx). Add new section 1.3.5.13: ------------------------- Mapping for java.lang.Enum The class java.lang.Enum is mapped to OMG IDL following the rules for mapping RMI/IDL value types defined in previous sections, with the exception that the ordinal field is not mapped to an OMG IDL data member. For example, this class could be mapped to the following OMG IDL: // IDL module java { module lang { valuetype _Enum: ::java::lang::Comparable { private ::CORBA::WStringValue name_; ::CORBA::WStringValue name( ); }; #pragma ID _Enum "RMI:java.lang.Enum:CA9967EE1176F5B3:0000000000000000" }; }; Add new section 1.3.5.14: ------------------------- Mapping for Java enum types Java enum types are mapped to OMG IDL following the rules for mapping RMI/IDL value types defined in previous sections, with the exception that their fields are not mapped to OMG IDL data members. For example, the Java enum public enum Direction { NORTH (0), SOUTH (180), EAST (90), WEST (270); public final int bearing; Direction(int bearing) { this.bearing = bearing; } } could be mapped to the following OMG IDL: // IDL valuetype Direction: ::java::lang::_Enum { }; #pragma ID Direction "RMI:Direction:332C04E72E3DB2A1:0000000000000000" Changes to section 1.5.1.5 -------------------------- At the end of the description of the readValue method, add the following: If clz is an enum class, readValue returns the singleton enum constant that is the result of calling the java.lang.Enum.valueOf() method passing clz and the string name of the enum constant unmarshaled from the mapped enum valuetype in the stream. At the end of the description of the getRMIRepositoryID method, add the following: If clz is an anonymous class for an enum constant with a class body (i.e., its superclass is not java.lang.Enum), then the getRMIRepositoryID method returns the RMI-style repository ID string for the named superclass of clz.
Actions taken:
September 5, 2006: received issue
July 30, 2007: closed issue

Discussion:
Resolution: Closed, accepted. See revised text below