JAV2I14 — Request clarification on copyObject(s) semantics

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