Issue 16587: API Should Avoid Side-Effects, e.g. Remove Bucket Accessors (dds-psm-java-ftf) Source: PrismTech (Dr. Angelo Corsaro, PhD., angelo.corsaro(at)prismtech.com) Nature: Revision Severity: Significant 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. Resolution: Revised Text: Actions taken: October 11, 2011: received issue Discussion: [Angelo] Proposal: The solution suggested to avoid bucket accessors and thus side effects is to rely as much as possible on immutable objects (e.g. true 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. [Rick] The other place there is a high cost of new allocations in on the critical read/take and write paths. I agree that the number of occurrences of this pattern can be reduced. But due to the complexity of choosing which ones to change, and the late submission date of this issue, I recommend deferring it. Resolution: Defer this issue. It was submitted after the comment deadline. Disposition: Deferred End of Annotations:===== m: Angelo Corsaro Subject: [DDS-PMS-Java Issue]: Bucket Accessors Date: Tue, 11 Oct 2011 10:45:52 +0200 Cc: Juergen Boldt To: issues@omg.org, dds-psm-java-ftf@omg.org X-Mailer: Apple Mail (2.1244.3) Name: Angelo Corsaro Employer: PrismTech eMail: angelo@icorsaro.net Specification: DDS PSM for Java5 (DDS-PSM-Java) Version: Beta 1 Title: API Should Avoid Side-Effects, e.g. Remove Bucket Accessors Nature: Architectural Severity: Major 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. -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 ------------------------------------------------------------------------------------------------------------------ http://icorsaro.net | http://twitter.com/acorsaro | http://slideshare.net/angelo.corsaro ------------------------------------------------------------------------------------------------------------------