DDS-Java 1.0b2 FTF Avatar
  1. OMG Issue

DDSJAVA — API Should Avoid Side-Effects, e.g. Remove Bucket Accessors

  • Key: DDSJAVA-35
  • Legacy Issue Number: 16587
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Description
    ----------------
    The DDS-PSM-Java provides bucket accessors that allow to "return" an object
    by "filling" a method parameter.

    As an example, for a property Foo there would be a method:

    Foo f = // some foo
    x.getFoo(f)

    The rationale for this API is to avoid a defensive copy of Foo each time it is accessed.
    However the cost of this "optimization" is an API that has side-effects everywhere,
    with all the nasty implications of side-effects.

    Resolution
    ---------------
    The solution suggested to avoid bucket accessors and thus side-effects is to
    rely as much as possible on immutable objects (e.g. value-types). This ensures
    that (1) defensive copies are unnecessary since the attribute returned is immutable,
    and (2) new objects are created when new values are required.

    If properly designed (as shown on an issue posted on QoS and Policies) this approach
    not only leads to a simpler and safer API, but it also leads to actually save memory in most
    of the cases.

    The only case where the suggested approach has a cost is when a property changes
    very often. However, in many of these cases (often found in loops) the new JDK7
    escape analysis will help greatly help in dealing with the potential garbage as it
    will allocate these short-lived objects on the stack.

  • Reported: DDS-Java 1.0b1 — Tue, 11 Oct 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Proposed Resolution:
    The solution suggested to avoid bucket accessors and thus side-effects is to rely as much as possible on immutable objects (e.g. value-types). This ensures that (1) defensive copies are unnecessary since the attribute returned is immutable, and (2) new objects are created when new values are required.
    If properly designed (as shown on an issue posted on QoS and Policies) this approach not only leads to a simpler and safer API, but it also leads to actually save memory in most of the cases.
    The only case where the suggested approach has a cost is when a property changes very often. However, in many of these cases (often found in loops) the new JDK7 escape analysis will help greatly help in dealing with the potential garbage as it will allocate these short-lived objects on the stack.

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