JAV2I 1.4 MAILINGLIST Avatar
  1. OMG Issue

JAV2I14 — Request clarification on copyObject(s) semantics

  • Key: JAV2I14-5
  • Legacy Issue Number: 5991
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • 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.

  • Reported: JAV2I 1.3 — Mon, 7 Jul 2003 04:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT