Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of jessewilson@google.com
 designates 216.239.33.17 as permitted sender)
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:in-reply-to:references:from:date:message-id:
	subject:to:content-type:x-system-of-record;
	b=nTNbUKDRL0zsJkUniD9jrLBcSws0w5bQ/67zlfldI9o0mB9ZlZA+Fn7fAjbwc+ING
	pRV4KQLwYjQOpstPsyF6g==
MIME-Version: 1.0
In-Reply-To: <200911100947.nAA9lnWh016473@d12av03.megacenter.de.ibm.com>
References: <354827273.1256589182512.JavaMail.jira@brutus>
	<4AE701B6.3010405@gmail.com>
 <a43fbc6a0910270932x785b1a64pf454995f940a9e59@mail.gmail.com>
	<200911100947.nAA9lnWh016473@d12av03.megacenter.de.ibm.com>
From: Jesse Wilson <jessewilson@google.com>
Date: Tue, 10 Nov 2009 11:38:01 -0800
Message-ID: <a43fbc6a0911101138i61365ccey3d9c557674fca3a9@mail.gmail.com>
Subject: Re: [classlib][modularity] Logging performance improvements
	(HARMONY-6362)
To: dev@harmony.apache.org
Content-Type: multipart/alternative; boundary=0015176f03e0e24f5804780973d8

--0015176f03e0e24f5804780973d8
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 10, 2009 at 1:47 AM, Mark Hindess
<mark.hindess@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.

--0015176f03e0e24f5804780973d8--