...
In this noncompliant code example, the PrintableIPAddressList class PrintableIPAddressList extends the thread-safe class IPAddressList. It PrintableIPAddressList locks on IpAddressList's member .ips in the method addAndPrintIPAddresses(). This is another example of client-side locking, because a subclass uses an object owned and locked by its superclass.
| Code Block |
|---|
|
// This class may change its locking policy in the future, for example,
// whenif new non-atomic methods are added
class IPAddressList {
private final List<InetAddress> ips = Collections.synchronizedList(new ArrayList<InetAddress>());
public List<InetAddress> getList() {
return ips; // No defensive copies required as package-private visibility
}
public void addIPAddress(InetAddress address) {
ips.add(address);
}
}
class PrintableIPAddressList extends IPAddressList {
public void addAndPrintIPAddresses(InetAddress address) {
synchronized(getList()) {
addIPAddress(address);
InetAddress[] ia = (InetAddress[]) getList().toArray(new InetAddress[0]);
// ...
}
}
}
|
| Wiki Markup |
|---|
If the class {{IPAddressList}} class is modified to use block synchronization on a private final lock object, as recommended by [CON04-J. Use private final lock objects to synchronize classes that may interact with untrusted code], the subclass {{PrintableIPAddressList}} will silently break. Moreover, whenif a wrapper such as {{Collections.synchronizedList()}} is used, it is unwieldydifficult for a client to determine the type of the class ({{List}}) that is being wrapped to extend it \[[Goetz 06|AA. Java References#Goetz 06]\]. |
Compliant Solution (Composition)
This compliant solution wraps an object of class IPAddressList and provides synchronized accessors that can be used to manipulate the state of the object.
Composition offers encapsulation benefits at the cost of performance. The performance impact is usually minimal; usually with minimal overhead. Refer to OBJ07-J. Understand how a superclass can affect a subclass for more information on implementing composition. This compliant solution wraps an object of class IPAddressList and provides synchronized accessors that can be used to manipulate the state of the object.
| Code Block |
|---|
|
// Class IPAddressList remains unchanged
class PrintableIPAddressList {
private final IPAddressList ips;
public PrintableIPAddressList(IPAddressList list) {
this.ips = list;
}
public synchronized void addIPAddress(InetAddress address) {
ips.addIPAddress(address);
}
public synchronized void addAndPrintIPAddresses(InetAddress address) {
addIPAddress(address);
InetAddress[] ia = (InetAddress[]) ips.getList().toArray(new InetAddress[0]);
// ...
}
}
|
| Wiki Markup |
|---|
This approachIn this case, composition allows the {{CompositeCollection}} class to use its own intrinsic lock in a way that is completely independent of the lock of the underlying list class. This allows the underlying collection to be not thread-safe because the {{CompositeCollection}} wrapper prevents direct access to its methods by publishing its own synchronized equivalents. This approach provides consistent locking even if the underlying class changes its locking policy in the future. \[[Goetz 06|AA. Java References#Goetz 06]\] |
...
