Issues for Java to IDL RTF Discussion Mailing List

List of Open Issues. Other options: All Issues; Closed Issues.

(red=unresolved; yellow=pending Board vote)

Summary: This item affects the Java-to-IDL spec, but is also of concern to the
 IDL-to-Java RTF because it relates to the new portability stub APIs.
 
 Section 7.2.2 of the Java to IDL mapping specifies a new interface
 ResponseHandler with methods createReply and createExceptionReply.
 These methods are declared as public.
 
 Section 9.4 of the Java Language Specification states that "Every
 method declaration in the body of an interface is implicitly public.
 It is permitted, but strongly discouraged as a matter of style, to
 redundantly specify the public modifier for interface methods."
 
 I propose that the public modifier be removed from these method
 declarations.
 

Summary: This item affects the Java-to-IDL spec, but is also of concern to the
 IDL-to-Java RTF because it relates to the new portability stub APIs.
 
 An orb() method is needed on org.omg.CORBA.portable.InputStream for
 SerializationInputStream to call to find which ORB to use for 
 lookup_value_factory during execution of read_Value.
 
 I propose adding an orb() method to org.omg.CORBA.portable.InputStream.
 

Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of 
 concern to the IDL-to-Java RTF because it affects the IDL-to-Java
 mapping.
 
 How do SerializationInputStream and SerializationOutputStream marshal
 Any, Context, Principal, and TypeCode objects?  Is the same mechanism
 used as for user-defined IDL types, i.e., look for the IDLEntity
 marker interface and call the implementation helper class"s write
 or read method?  If so, we need to clarify that vendor implementation
 of these types must implement IDLEntity and provide a Helper class.
 
 I propose that we state in the spec that vendor implementations	of 
 these types must implement IDLEntity and provide a Helper class.
 

Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of 
 concern to the IDL-to-Java RTF because it affects the IDL-to-Java
 mapping.
 
 When adding support for idlToJava generated Stubs to 
 "InputStream.read_Object(java.lang.Class clz)" we ran into a small 
 problem while writing the code.  Initially we used "clz.newInstance()"
 to create an instance of the Stub object.  The problem here is the 
 Stub does not have a default constructor, so newInstance throws an
 exception.  We added a default constructor to the stub and everything
 worked fine.  The question is: should we add a default constructor to
 the stubs generated by idlToJava or should we use reflection(cost??) to
 invoke the one constructor that is already a member of the stub class?
 
 I propose that we state in the spec that a default constructor is
 required on all generated Stubs.
 
 

Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of 
 concern to the IDL-to-Java RTF because it affects the IDL-to-Java
 mapping.
 
 The Java to IDL mapping spec states that Java types produced by
 the direct mapping should implement IDLEntity and be serializable.
 This could be accomplished by having IDLEntity extend 
 Java.io.Serializable, or by having the generated types extend
 both IDLEntity and java.io.Serializable.  The spec should
 specify which of these approaches is to be used.
 

Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of 
 concern to the Objects By Value RTF because it affects the Java
 ORB implementation of Objects By Value.
 
 The currently specified delegation relationship between 
 SerializationInputStream and SerializationOutputStream and their
 underlying ORB stream classes is inefficient and awkward.
 It is awkward because it requires the ORB implementation of the
 underlying streams to know about their "wrapper" serialization
 streams and to be careful to always pass out a reference to the
 wrapper instead of a "this" pointer.  It is inefficient because
 all items (even primitives) that are written to these streams 
 need to go through an extra delegation step through the wrapper 
 class as the underlying stream does not know whether it can
 safely bypass the wrapper method.
 

Summary:  The Unicode example given in the spec (5.2.4) is x\u22aBy
     javac diagnoses \u22aB as an invalid character in an identifier.
 
     A Java identifier may only consist of Unicode characters that denote a
     letter or a digit in a language. \u22aB (apparently) does not.
 
     Try \u03bC instead. According to 8.2.1 it"s a Greek mu. javac is happy
     with it.
 
     Proposed resolution: fix example
 

Summary:  mapping for nested sequences:
     - error in section 5.6 sequence<seq_Y>
     - no occurrence of >> so no need for white space
 
     Proposed resolution: fix example in section 5.6
 

 resolved, close issue

Summary: 10. Need to emit ID pragmas after declarations
 

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

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

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

 In section 5.7.4, example IDL, change

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

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

 received issue

Summary: 17. Need to clarify rules for mapping server-side errors and runtime
     exceptions back to client exceptions.
 
     Proposed resolution: use omg.omg.CORBA.UNKNOWN
 
 

 issue resolved and fixed

Summary: The generated IDL in A2 needs to be changed.
 
     In particular, forward declares for fred.Test2 and fred.Stuff must
     appear before #includes, before sequence defs and before the module
     definition. Their #includes must appear at the end. In fact, just follow
     the file layout rules described at the beginning of the appendix. 
 
     If this is not done, there is a danger that circular references will
     lead to undeclared types when the IDL is compiled.
 
     Proposed resolution: fix example
 

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

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

 No.--close issue

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

Summary: 25. Should exportObject throw exceptions?
 

 received issue

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

 received issue

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

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

Summary: RMI/JRMP stubs provide overridden implementations for the
 hashCode, equals, and toString methods of java.lang.Object.
 
 The stub hashCode method returns the same hash code for
 different stubs that refer to the same remote object.
 The stub equals method returns true when stubs that refer
 to the same remote object are compared.  These methods allow
 remote objects to be held in Java collections.
 
 The stub toString method returns a string containing information
 about the remote object, not the local stub.
 
 RMI/IIOP stubs should provide equivalent methods.  The easiest
 way to do this is to add implementations of these three methods
 to the javax.rmi.CORBA.Stub base class.
 
 I propose that the definition of javax.rmi.CORBA.Stub in
 section 7.2.5 be modified to add these methods.
 

Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of 
 concern to the IDL-to-Java RTF because it affects the IDL-to-Java
 mapping.
 
 Three of the new portability APIs intorduced by the Java to IDL mapping
 are declared as throwing org.omg.CORBA.SystemException.  These are
 the _invoke methods of ObjectImpl and Delegate and the _invoke method
 of InvokeHandler.  I don"t think this exception hould be declared
 explicitly, since it is a subclass of java.lang.RuntimeException and so 
 is always implictly throwable whether it is declared or not.  Also, 
 other portability APIs can throw this exception even though they do not 
 declare it explicitly.  This inconsistency makes it very difficult for
 the reader of the spec to determine which of the portability APIs can
 throw CORBA system exceptions, and is likely to cause confusion.
 
 I propose that org.omg.CORBA.SystemException be removed from the throws
 clause of the above-mentioned APIs.
 

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

Summary: orbos/98-02-01 says:
 
 	We have provided name manglings to work around [the limitations],
 	but we recommend that OMG consider extending the definitions of
 	IDL identifiers so that a wider range of unicode characters can
 	be supported and so that case is significant in distinguishing
 	identifiers.
 
 I would suggest to remove this recommendation because it is pragmatically
 unimplementable for implementation languages that do not support
 extended character sets. If the OMG were to take this step, it would
 effectively alienate CORBA from all such implementation languages, which
 I believe would be detrimental to the success of CORBA.
 
 	Because overloaded methods are a popular feature in object-oriented
 	programming languages we recommend that OMG considers extending
 	IDL to allow overloaded methods.
 
 Again, I suggest to remove the recommendation because it is pragmatically
 unimplementable. Steve Vinoski recently posted an interesting article
 on this topic in comp.object.corba -- I have attached a copy below.
 

Summary: In section 7.1.2, there is a method called read_AbstractObject(clz).
 I propose that we change its name to read_Abstract to bring it
 into line with the read_Abstract() method introduced in section
 8.7.1 of the OBV spec.  This is consistent with having methods
 called read_Object() and read_Object(clz).
 
 There"s also a typo in section 7.2.6.  It says that 
 Util.write_AbstractObject calls OutputStream.write_AbstractObject.
 This should say OutputStream.write_Abstract.
 
 
 

Summary: The Java-to-IDL spec says in section 6.6.1 that certain CORBA system
 exceptions are mapped to the Java exceptions
   javax.jts.TransactionRequiredException
   javax.jts.TransactionRolledBackException
   javax.jts.InvalidTransactionException
 
 The names above are obsolete (since Sun revised the JTS/JTA specs),
 so the Java-to-IDL spec needs to be changed.  Possible mappings are:
  1. javax.transaction.<the_same_names_as_above>
       (as listed in the JTA spec)
  2. java.rmi.RemoteException
  3. No mapping (leave them as CORBA system exceptions) 
 
 Option 1 implies a dependency of the RMI-IIOP runtime on these
 JTA exception classes.  
 
 

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

Summary: The spec needs to say what happens if a Java public RMI/IDL
 value class has data members whose types are not public.
 
 Options: Either a) restrict all uses of non-public types, or 
 b) map all non-public types to public in IDL.
 
 Inprise have proposed that we adopt option b).  Comments?
 

Summary: There is an issue with the currently specified mapping for Java
 remote and abstract interfaces containing methods that throw 
 superclasses of java.rmi.RemoteException but do not throw
 java.rmi.RemoteException.  In Java 1.1, these are not recognized
 as RMI remote interfaces.  In Java 1.2, these are recognized as
 RMI remote interfaces. 
 
 I propose that throwing these superclass exceptions be treated by
 the Java to IDL mapping as semantically equivalent to throwing
 both RemoteException and the superclass exception.  This means
 that the section 4.3 rules for RMI/IDL remote interfaces would 
 be changed to include this case (in point 3), with similar changes
 elsewhere in the spec.
 

Summary: Generated names in the ::org::omg::sequences module can clash.
 For example, a Java array of type foo[][] and a Java array of type
 seq_foo[] both map to ::org::omg::sequences::seq_seq_foo.
 
 I propose that instead of using repeated "seq_" prefixes for the 
 array dimensions, a single prefix "seq<n>_", where <n> is the
 number of dimensions, should be used.  This ensures no clashes.
 In the example above, these Java types would map to seq2_foo and 
 seq1_seq_foo.
 

Summary: An RMI-JRMP server creates and exports server objects and then
 returns.  A non-daemon thread created by the JRMP runtime keeps the
 server process alive until there are no more objects exported.
 For code portability, an RMI-IIOP server needs to work in a similar
 way.  It is not acceptable to require a call to ORB.run() or the
 use of application "wait" code to keep the server process alive.
 
 I propose that the specification of PortableRemoteObject.exportObject
 be updated to say that the first call to this creates a non-daemon
 thread which keeps the JVM alive until all exported objects have
 been unexported by calls to PortableRemoteObject.unexportObject.
 

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

 issue resolved and closed

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

Summary: The proposal here is to map Object, Serializable and Externalizable
 to distinct entities, rather than just to an any.
 
 These entities are
 module java {
     module lang {
        typedef any _Object;
     };
     module io {
         typedef any Serializable;
         typedef any Externalizable;
     };
 };
 
 and so
 java.lang.Object will map to ::java::lang::_Object,
 java.io.Serializable will map to ::java::io::Serializable, and
 java.io.Externalizable will map to ::java::io.Externalizable
 

Summary: Moving forward to JDK 1.2, the IDL value type data mapping needs
 to factor in the new serialPersistentFields declaration.  And there"s
 an interesting question whether the existence of a writeReplace method
 should influence the decision to map to a custom value.
 

 Adopted proposal:

Summary: 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?
 

Closed, no change. See revised text below.

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.
 

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.
 

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.

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.

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.

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:

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.

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.

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?

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

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: Closed, no change. See revised text below.

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

Closed as duplicate of issue 6410.

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

Closed, accepted. See revised text below.

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

Closed, accepted. See revised text below

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.

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: Closed, accepted. See revised text below

Resolution: Closed, accepted. See revised text below