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.

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

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
}

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?

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