Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of enh@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:date:message-id:subject:from:to:
	content-type:content-transfer-encoding:x-system-of-record;
	b=CSuNeZUQbHLj08mrc3fFiL2yVbFjhTJ9fpEcaDBrvSPyN90BC53Q580191RHBzTeS
	M6Tr/eT3pJpppGVVAGEPg==
MIME-Version: 1.0
In-Reply-To: <4AFBE714.60702@gmail.com>
References: <354827273.1256589182512.JavaMail.jira@brutus>
	 <4AE701B6.3010405@gmail.com>
	 <a43fbc6a0910270932x785b1a64pf454995f940a9e59@mail.gmail.com>
	 <4AF807A5.7080400@gmail.com>
	 <a43fbc6a0911091431r263b8dfco1ae1bfa59061ffb@mail.gmail.com>
	 <4AFBE714.60702@gmail.com>
Date: Thu, 12 Nov 2009 14:32:19 -0800
Message-ID: <96933a4d0911121432mb5e0d88we33965c32c578434@mail.gmail.com>
Subject: Re: [classlib][modularity] Logging performance improvements
	(HARMONY-6362)
From: enh <enh@google.com>
To: dev@harmony.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 12, 2009 at 02:44, Tim Ellison <t.p.ellison@gmail.com> wrote:
> On 09/Nov/2009 22:31, Jesse Wilson wrote:
>> On Mon, Nov 9, 2009 at 4:14 AM, Tim Ellison <t.p.ellison@gmail.com> wrot=
e:
>>
>>> I didn't mean to ask "Why is a CopyOnWriteArrayList useful?", rather
>>> what did it contribute to your logging improvements, e.g. correctness
>>> that would require tons of duplicate coding otherwise, or performance
>>> numbers, etc. (however, see below)
>>
>> Using CopyOnWriteArrayList permitted me to strip off "synchronized" from
>> getHandlers(). This makes it possible for multiple threads to log messag=
es
>> concurrently without contention.
>>
>>> The ability to consume modules from harmony without having to deal with
>>> inter-module spaghetti code is worth preserving.
>>
>> Okay, I'll bite. Why is it worth preserving? We agree that it's useful f=
or
>> projects to take some modules from Harmony and some from external source=
s.
>> Android gets most of its modules from Harmony, but has its own regex mod=
ule.
>> But Android still *has* a regex module.
>
> And I'd argue that the reason groups like Android /can/ pick up
> alternative implementations is because we minimize the coupling between
> the modules.
>
> Maybe we need to make a finer distinction,
>
> (a) non-API dependencies: so to take your example, if (say) LUNI had
> links into the internal workings of Harmony's regex implementation there
> would have been more places for you to hack the LUNI code to make it
> work with your implementation of regex. =C2=A0Minimizing the
> non-(standard)-API dependencies is a good thing.

i don't think anyone's arguing otherwise.

> (b) API dependencies: some are placed upon us by the spec, and some are
> quite bizzare or unfortunate. =C2=A0So I the reason I need to have an App=
let
> implementation in order to compile our Beans implementation is because
> there is a standard API dependency between them. =C2=A0But without such
> requirements it would be madness to have such gratuitous dependencies.

again, i don't think anyone's arguing otherwise.

i forget who it was made a distinction between headless and
non-headless classes, but i think that's a good one. "java" versus
"javax/org/com" is a pretty good one too.

> The knack is deciding which are gratuitous, and which are reasonable.
> I'm happy to say that concurrent is common enough and a useful utility
> that we can say 'go at it' to implement the other modules in terms of
> concurrency APIs -- but if some bright spark wants to use the event
> mechanism from Swing then I'd object.
>
> (Not a fictitious example, there are plenty of examples of notionally
> headless code that drag in this dependency.)

i wouldn't have believed it if i hadn't seen it with my own eyes, but
there was an Android bug asking us to include the swing model classes
because they had some non-gui code that was using [iirc]
DefaultTreeModel.

(obviously, we agree that's a bad idea, and don't want to encourage it.)

>> Is anyone reusing modules from Harmony on a system that won't have a
>> java.util.concurrent package?
>
> As Mark points out, yes there are apparently; but if they are not
> prepared to come here and defend the argument then we get to make the
> decisions for them <g>.

we can also use "argument by authority" and point out that the back
cover of Effective Java says "...the language and its most fundamental
libraries: java.lang, java.util, and, to a lesser extent,
java.util.concurrent and java.io" ;-)

[btw, i followed the link, but didn't really understand what i was
looking at or how it demonstrated the case.]

>> I think it should be fair game for modules to depend upon the
>> published APIs of other modules in their implementation details.
>
> Within reason.

maybe a useful rule of thumb is "if we wrote something here from
scratch, would it be better or worse than reusing existing public
classes?".

in the DefaultTreeModel case, special-purpose code would be a more
intention-revealing model of what they were really doing, and would be
small and hard to get wrong.

in the case of some internal cache, there's almost nothing to gain
from rolling our own concurrent data structures and any half-decent
implementation is large and hard to do well.

 --elliott

>>> I'm prepared to accept that concurrent becomes part of the fundamental
>>> core classes that are used to implement the remainder of the class
>>> libraries. =C2=A0I'd be less happy about seeing lots of references to, =
say,
>>> logging scattered throughout the other modules. =C2=A0We should remain =
modest
>>> in our dependencies.
>>
>> In Android the luni module depends on our logging module! From our
>> BufferedOutputStream<http://android.git.kernel.org/?p=3Dplatform/dalvik.=
git;a=3Dblob;f=3Dlibcore/luni/src/main/java/java/io/BufferedOutputStream.ja=
va;h=3D835d13f153b6d2baff48621a596aa531bf42fffb;hb=3Dmaster>class,
>>
>> =C2=A068 <#l68> =C2=A0 =C2=A0 public BufferedOutputStream(OutputStream o=
ut) {
>> =C2=A069 <#l69> =C2=A0 =C2=A0 =C2=A0 =C2=A0 super(out);
>> 70 <#l70> =C2=A0 =C2=A0 =C2=A0 =C2=A0 buf =3D new byte[8192];
>> =C2=A071 <#l71>
>> =C2=A072 <#l72> =C2=A0 =C2=A0 =C2=A0 =C2=A0 // BEGIN android-added
>> =C2=A073 <#l73> =C2=A0 =C2=A0 =C2=A0 =C2=A0 /*
>> 74 <#l74> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * For Android, we want to discoura=
ge the use of this
>> constructor (with
>> =C2=A075 <#l75> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * its arguably too-large def=
ault), so we note its
>> use in the log. We
>> =C2=A076 <#l76> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * don't disable it, nor do w=
e alter the default,
>> however, because we
>> =C2=A077 <#l77> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * still aim to behave compat=
ibly, and the default
>> value, though not
>> =C2=A078 <#l78> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* documented, is estab=
lished by convention.
>> =C2=A079 <#l79> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
>> =C2=A080 <#l80> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Logger.global.info(
>> =C2=A081 <#l81> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"=
Default buffer size used in BufferedOutputStream " +
>> =C2=A082 <#l82> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
"constructor. It would be " +
>> =C2=A083 <#l83> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"=
better to be explicit if an 8k buffer is required.");
>> =C2=A084 <#l84> =C2=A0 =C2=A0 =C2=A0 =C2=A0 // END android-added
>> =C2=A085 <#l85> =C2=A0 =C2=A0 }
>>
>>
>> Java.util.logging provided a suitable vehicle for emitting a warning. We
>> haven't seen any problems caused by the coupling between luni and loggin=
g
>> modules. Now I'm not suggesting that we rush in to add coupling between
>> Harmony's modules, but I fail to see how the coupling is harmful. I also
>> think that the duplication in the resource bundling code is far worse th=
an
>> the coupling it prevents.
>
> I assume you mean the I18N resource handling? in which case, yes, I
> agree that is not such a bright idea. =C2=A0There are people who take mod=
ules
> (e.g. pack200) but not LUNI, I wouldn't mind if they had to copy the
> resource handling code themselves to be self-sufficient.
>
> Regards,
> Tim
>
>
>


--=20
Elliott Hughes - http://who/enh - http://jessies.org/~enh/