Page History

According to Goetz and colleagues \[[Goetz 2006|AA. Bibliography#GoetzReferences#Goetz 06]\]:

While client-side locking is acceptable when the thread-safe class commits to and clearly documents its locking strategy, Goetz and colleagues caution against its misuse \[[Goetz 2006|AA. Bibliography#GoetzReferences#Goetz 06]\]:

The documentation of a class that supports client-side locking should explicitly state its applicability. For example, the class {{java.util.concurrent.ConcurrentHashMap<K,V>}} should not be used for client-side locking because its documentation \[[API 2006|AA. Bibliography#APIReferences#API 06]\] states that:

Use of client-side locking is permitted only when the documentation of the class recommends it. For example, the documentation of the {{synchronizedList()}} wrapper method of {{java.util.Collections}} class \[[API 2006|AA. Bibliography#APIReferences#API 06]\] states 

Goetz and colleagues describe the fragility of class extension for adding functionality to thread-safe classes \[[Goetz 2006|AA. Bibliography#GoetzReferences#Goetz 06]\]:

If the {{IPAddressList}} class were modified to use block synchronization on a private final lock object, as recommended by rule [LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code], the {{PrintableIPAddressList}} subclass would silently break. Moreover, if a wrapper such as {{Collections.synchronizedList()}} were used, it would be difficult for a client to determine the type of the class being wrapped to extend it \[[Goetz 2006|AA. Bibliography#GoetzReferences#Goetz 06]\].

In this case, composition allows the {{PrintableIPAddressList}} class to use its own intrinsic lock independent of the underlying list class's lock. The underlying collection lacks a requirement for thread-safety because the {{PrintableIPAddressList}} wrapper prevents direct access to its methods by publishing its own synchronized equivalents. This approach provides consistent locking even when the underlying class changes its locking policy in the future \[[Goetz 2006|AA. Bibliography#GoetzReferences#Goetz 06]\].