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?

No Data Available

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

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

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available