Issue 16529: Modifiable Types should be removed and replaced by values (e.g. immutable types). (dds-psm-java-ftf) Source: PrismTech (Dr. Angelo Corsaro, PhD., angelo.corsaro(at)prismtech.com) Nature: Revision Severity: Significant Summary: The dds-psm-java introduces modifiable versions for conceptually immutable classes as a way to safe a few object allocations. However this is done for QoS which are not changed so often and that are overall very "thin" object. [Suggested Resolution] The proposed resolution is to get rid of this modifiable types and to ensure that value types are used everywhere. Althought this solution might lead to think that immutable types induce the creation of more objects this is not necessarily the case if the API si designed carefully as done for policies and Qos on simd-java (see git@github.com:kydos/simd-java.git). As an example, with the API included in the current DDS-PSM-Java modifying a policy would require the following steps: // Get unmodifiable QoS for inspection: DataWriterQos udwq = dw.getQos(); // Get the Modifiable QoS ModifiableDataWriterQos mdwq = udwq.modify(); // Modify the Qos mdwq.setReliability(...); With immutable Policies and QoS the same code could be rewritten as follows: DataWriterQos dwq = dw.getQos().with(Reliability.Reliable()); But you could also do: DataWriterQos dwq = dw.getQos().with( Reliability.Reliable(), Durability.Transient()); Notice that both code fragment both lead the lead the creation of a single new object. Yet the propsed approach not only gets rid of the complexity of the mutable objects, but it also get rids of the danger introduced by having mutable objects into multi-threaded applications. In summary, the proposed change (1) simplifies the API, (2) makes it safer, and (3) does not introduce runtime overhead (it actually allows for an higher degree of object sharing and thus better space efficiency). NOTE: Cloneable interface No need to implement the interface once the mutable pkg is removed Resolution: Revised Text: Actions taken: September 7, 2011: received issue Discussion: [Angelo] The proposed resolution is to get rid of these modifiable types and to ensure that value types are used everywhere. Although this solution might lead to think that immutable types induce the creation of more objects this is not necessarily the case if the API is designed carefully as done for policies and QoS on simd-java (see git@github.com:kydos/simd-java.git). As an example, with the API included in the current DDS-PSM-Java modifying a policy would require the following steps: // Get unmodifiable QoS for inspection: DataWriterQos udwq = dw.getQos(); // Get the Modifiable QoS ModifiableDataWriterQos mdwq = udwq.modify(); // Modify the Qos mdwq.setReliability(...); With immutable Policies and QoS the same code could be rewritten as follows: DataWriterQos dwq = dw.getQos().with(Reliability.Reliable()); But you could also do: DataWriterQos dwq = dw.getQos().with( Reliability.Reliable(), Durability.Transient()); Notice that both code fragments lead to the lead the creation of a single new object. Yet the proposed approach not only gets rid of the complexity of the mutable objects, but it also get rids of the danger introduced by having mutable objects into multi-threaded applications. In summary, the proposed change (1) simplifies the API, (2) makes it safer, and (3) does not introduce runtime overhead (it actually allows for an higher degree of object sharing and thus better space efficiency). NOTE: Cloneable interface: No need to implement the interface once the mutable package is removed [Rick] Situational analysis: • The biggest occurrence of the modifiable/unmodifiable pattern is in the QoS policies and Entity QoS. • ModifiableDuration can easily go away. Duration is only returned from QoS policy property accessors; QoS policies are not performance-sensitive. And in every case where durations are passed as arguments, there are already overloads to use an integer and a TimeUnit. • ModifiableTime is used in two places: DomainParticipant.getCurrentTime and Sample.getSourceTimestamp. Both are performance-sensitive, although the latter could potentially be replaced by simply Time. Time is accepted as an argument in a number of DataWriter methods, though these can be easily eliminated: each already has an overload that accepts an integer and a TimeUnit. • ModifiableInstanceHandle is used in statuses and in lookupInstance, where it needs to support being copied over. However, other values—like the nil handle constant, Entity instance handles, and the result of registerInstance—should not be changed. All of these APIs can be performance-sensitive. • AnnotationDescriptor and MemberDescriptor from the Dynamic Type API are provided in modifiable and unmodifiable versions. This API is not performance-sensitive, so accessors could simply return new copies of modifiable types. Orlando meeting discussion: • Consider replacing this pattern with a more explicit Builder pattern (see issue #15966) and/or a DSL (see issue #16536) in the case of Entity QoS and QoS policies. • Eliminate ModifiableDuration and leave Duration as an immutable type. Eliminate method overloads that accept Duration as an argument, leaving in place those that accept an integer and a TimeUnit. • Implement a lighter-weight version of this pattern specifically for Time and InstanceHandle rather than retaining it for all value types. To avoid race conditions, these classes should NOT be related by inheritance. • Remove AnnotationDescription, renaming ModifiableAnnotationDescriptor to AnnotationDescriptor. Remove MemberDescription, renaming ModifiableMemberDescriptor to MemberDescription. • Remove all “modifiable” packages. Resolution: Defer this issue. This issue was filed after the comment deadline, and its resolution will have a broad impact and has dependencies on the resolutions of other issues. It will be better to address it later, when there is sufficient time to make and review the changes thoroughly. Disposition: Deferred End of Annotations:===== m: Angelo Corsaro Subject: [DDS-PSM-JAVA ISSUE]: Modifiable Types should be removed and replaced by values (e.g. immutable types). Date: Wed, 7 Sep 2011 18:50:22 +0200 Cc: Juergen Boldt To: dds-psm-java-ftf@omg.org, issues@omg.org X-Mailer: Apple Mail (2.1084) [Name] Angelo Corsaro [Employer] PrismTech [eMail] angelo@icorsaro.net [Specification] DDS PSM for Java5 (DDS-PSM-Java) [Version] Beta 1 [Title] Modifiable Types should be removed and replaced by values (e.g. immutable types). [Nature] Architectural [Severity] Major [Description] The dds-psm-java introduces modifiable versions for conceptually immutable classes as a way to safe a few object allocations. However this is done for QoS which are not changed so often and that are overall very "thin" object. [Suggested Resolution] The proposed resolution is to get rid of this modifiable types and to ensure that value types are used everywhere. Althought this solution might lead to think that immutable types induce the creation of more objects this is not necessarily the case if the API si designed carefully as done for policies and Qos on simd-java (see git@github.com:kydos/simd-java.git). As an example, with the API included in the current DDS-PSM-Java modifying a policy would require the following steps: // Get unmodifiable QoS for inspection: DataWriterQos udwq = dw.getQos(); // Get the Modifiable QoS ModifiableDataWriterQos mdwq = udwq.modify(); // Modify the Qos mdwq.setReliability(...); With immutable Policies and QoS the same code could be rewritten as follows: DataWriterQos dwq = dw.getQos().with(Reliability.Reliable()); But you could also do: DataWriterQos dwq = dw.getQos().with( Reliability.Reliable(), Durability.Transient()); Notice that both code fragment both lead the lead the creation of a single new object. Yet the propsed approach not only gets rid of the complexity of the mutable objects, but it also get rids of the danger introduced by having mutable objects into multi-threaded applications. In summary, the proposed change (1) simplifies the API, (2) makes it safer, and (3) does not introduce runtime overhead (it actually allows for an higher degree of object sharing and thus better space efficiency). NOTE: Cloneable interface No need to implement the interface once the mutable pkg is removed -- 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 ------------------------------------------------------------------------------------------------------------------ From: Richard Warren To: "dds-psm-java-ftf@omg.org" Date: Thu, 22 Sep 2011 07:32:07 -0700 Subject: Re: issue 16529 -- Java 5 Language PSM for DDS 1.0 FTF issue Thread-Topic: issue 16529 -- Java 5 Language PSM for DDS 1.0 FTF issue Thread-Index: Acx5NGjGudO/Kh+HSbqzoB/Va3P2hQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Hi, I have looked over the use of the modifiable/unmodifiable framework, and this is what I've found: Situational analysis: · The biggest occurrence of the modifiable/unmodifiable pattern is in the QoS policies and Entity QoS. · ModifiableDuration can easily go away. Duration is only returned from QoS policy property accessors; QoS policies are not performance-sensitive. And in every case where durations are passed as arguments, there are already overloads to use an integer and a TimeUnit. · ModifiableTime is used in two places: DomainParticipant.getCurrentTime and Sample.getSourceTimestamp. Both are performance-sensitive, although the latter could potentially be replaced by simply Time. Time is accepted as an argument in a number of DataWriter methods, though these can be easily eliminated: each already has an overload that accepts an integer and a TimeUnit. · ModifiableInstanceHandle is used in statuses and in lookupInstance, where it needs to support being copied over. However, other values.like the nil handle constant, Entity instance handles, and the result of registerInstance.should not be changed. All of these APIs can be performance-sensitive. · AnnotationDescriptor and MemberDescriptor from the Dynamic Type API are provided in modifiable and unmodifiable versions. This API is not performance-sensitive, so accessors could simply return new copies of modifiable types. Recommendation: · Replace this pattern with a more explicit Builder pattern and/or a DSL in the case of Entity QoS and QoS policies. · Eliminate ModifiableDuration and leave Duration as an immutable type. Eliminate method overloads that accept Duration as an argument, leaving in place those that accept an integer and a TimeUnit. · Implement a lighter-weight version of this pattern specifically for Time and InstanceHandle rather than retaining it for all value types. · Remove AnnotationDescription, renaming ModifiableAnnotationDescriptor to AnnotationDescriptor. Remove MemberDescription, renaming ModifiableMemberDescriptor to MemberDescription. · Remove all .modifiable. packages. Regards, - Rick -- Rick Warren Director of Technology Solutions RTI Tel 626.584.0141 rick.warren@rti.com www.rti.com RTI - The Global Leader in DDS From: Angelo Corsaro Subject: [DDS-PSM-JAVA ISSUE]: Modifiable Types should be removed and replaced by values (e.g. immutable types). Date: Wed, 7 Sep 2011 18:50:22 +0200 Cc: Juergen Boldt To: dds-psm-java-ftf@omg.org, issues@omg.org X-Mailer: Apple Mail (2.1084) [Name]Angelo Corsaro [Employer]PrismTech [eMail]angelo@icorsaro.net [Specification]DDS PSM for Java5 (DDS-PSM-Java) [Version] Beta 1 [Title]Modifiable Types should be removed and replaced by values (e.g. immutable types). [Nature]Architectural [Severity]Major [Description] The dds-psm-java introduces modifiable versions for conceptually immutable classes as a way to safe a few object allocations. However this is done for QoS which are not changed so often and that are overall very "thin" object. [Suggested Resolution] The proposed resolution is to get rid of this modifiable types and to ensure that value types are used everywhere. Althought this solution might lead to think that immutable types induce the creation of more objects this is not necessarily the case if the API si designed carefully as done for policies and Qos on simd-java (see git@github.com:kydos/simd-java.git). As an example, with the API included in the current DDS-PSM-Java modifying a policy would require the following steps: // Get unmodifiable QoS for inspection: DataWriterQos udwq = dw.getQos(); // Get the Modifiable QoS ModifiableDataWriterQos mdwq = udwq.modify(); // Modify the Qos mdwq.setReliability(...); With immutable Policies and QoS the same code could be rewritten as follows: DataWriterQos dwq = dw.getQos().with(Reliability.Reliable()); But you could also do: DataWriterQos dwq = dw.getQos().with( Reliability.Reliable(), Durability.Transient()); Notice that both code fragment both lead the lead the creation of a single new object. Yet the propsed approach not only gets rid of the complexity of the mutable objects, but it also get rids of the danger introduced by having mutable objects into multi-threaded applications. In summary, the proposed change (1) simplifies the API, (2) makes it safer, and (3) does not introduce runtime overhead (it actually allows for an higher degree of object sharing and thus better space efficiency). NOTE: Cloneable interface No need to implement the interface once the mutable pkg is removed -- 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 ---------------------------------------------------------------------------------