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.
