Legacy Issue Number: 16529
Source: ADLINK Advanced Technology Office ( Angelo Corsaro)
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.
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 firstname.lastname@example.org: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
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(
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).
No need to implement the interface once the mutable pkg is removed
Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
Disposition: Resolved — DDS-Java 1.0b2
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT