More Library Puzzlers - Java Puzzlers: Traps, Pitfalls, and Corner Cases - page 235

can interfere with a library class. For example, in all releases up to and including release 5.0, the
system requires the class lock on Thread in order to create a new Thread instance. Executing the
following code would prevent the creation of any new threads:
synchronized (Thread.class) {
Thread.sleep(Long.MAX_VALUE);
}
In summary, never make assumptions about what a library class will or won't do with its locks. To
isolate yourself from the use of locks by a library class, avoid inheriting from library classes except
those specifically designed for inheritance [EJ Item 15]. To guarantee that your locks are immune to
external interference, prevent others from gaining access to your locks by keeping them private.
For language designers, consider whether it is appropriate to associate a lock with every object. If
you elect to do so, consider restricting access to these locks. In Java, locks are effectively public
attributes of objects; perhaps it would make more sense if they were private. Also note that in Java,
an object effectively is a lock: You synchronize on the object itself. Perhaps it would make more
sense if an object had a lock that you could obtain by calling an accessor method.
< Day Day Up >