On 10/Nov/2009 19:38, Jesse Wilson wrote: > On Tue, Nov 10, 2009 at 1:47 AM, Mark Hindess > <mark.hind...@googlemail.com>wrote: > >> Since they aren't active on the list I'm not sure how much we should let >> this influence our decision. It does suggest that we should be cautious >> about making assumptions about what downstream users might like to do. >> I am reluctant to limit subsetting choices for (potential) downstream >> users without good reason. > > Well I guess the burden is on myself to provide a good reason! The > java.util.concurrent package is excellent; it is Java's best API. By > permitting its use by other modules, we will see increased correctness and > performance... > > Consider java.net.NegativeCache. This class uses a global lock to interact > with a LinkedHashMap concurrently. Upgrading to a more modern datastructure > like a ConcurrentHashMap can improve application throughput. Similarly for > the half dozen other caches in our code. > > Or perhaps InetAddress.isReachableByMultiThread(), which currently ignores > InterruptedExceptions while its background thread is working. > > And there's SystemProcess, whose create() method contains 4 synchronized > blocks. Perhaps this could benefit from java.util.concurrent? As it's > written currently, an OutOfMemoryError while allocating one of the three > buffers will cause the create() call to hang indefinitely. > > Writing code in 2009 without java.util.concurrent is like writing code with > your hand tied behind your back.
You *are* allowed to use your feet too though. Tim
