harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <ndbe...@apache.org>
Subject Re: [classlib][modularity] Logging performance improvements (HARMONY-6362)
Date Tue, 10 Nov 2009 03:52:39 GMT
On Mon, Nov 9, 2009 at 4:31 PM, Jesse Wilson <jessewilson@google.com> wrote:
> On Mon, Nov 9, 2009 at 4:14 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> 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 messages
> 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 for
> projects to take some modules from Harmony and some from external sources.
> Android gets most of its modules from Harmony, but has its own regex module.
> But Android still *has* a regex module.
> Is anyone reusing modules from Harmony on a system that won't have a
> java.util.concurrent package? I think it should be fair game for modules to
> depend upon the published APIs of other modules in their implementation
> details.

If it's out there, they certainly haven't popped up to say anything.

Over the past few years I've gotten less and less interested in
asserting the loose coupling of the modules. At this point, I'd rather
go for reducing the module count and go for some sort of non-milestone
release. I certainly think there are separations that should be
maintained, but I think there are a few that could be rolled together
without any real concern.

- Pull in all of the java.util.* into LUNI
- Pull annotation into LUNI
- Consider pulling lang-management into LUNI (this one's tough because
of jmx dependencies)
- Pull AWT and Swing together
- Pull nio-char into nio

Honestly, at this point, I think the biggest strength of Harmony's
Class Library is the separation of UI and non-UI stuff. A JVM +
headless classlibrary is very attractive.

> 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.  I'd be less happy about seeing lots of references to, say,
>> logging scattered throughout the other modules.  We 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=platform/dalvik.git;a=blob;f=libcore/luni/src/main/java/java/io/BufferedOutputStream.java;h=835d13f153b6d2baff48621a596aa531bf42fffb;hb=master>class,
>  68 <#l68>     public BufferedOutputStream(OutputStream out) {
>  69 <#l69>         super(out);
> 70 <#l70>         buf = new byte[8192];
>  71 <#l71>
>  72 <#l72>         // BEGIN android-added
>  73 <#l73>         /*
> 74 <#l74>         * For Android, we want to discourage the use of this
> constructor (with
>  75 <#l75>         * its arguably too-large default), so we note its
> use in the log. We
>  76 <#l76>         * don't disable it, nor do we alter the default,
> however, because we
>  77 <#l77>         * still aim to behave compatibly, and the default
> value, though not
>  78 <#l78>          * documented, is established by convention.
>  79 <#l79>          */
>  80 <#l80>         Logger.global.info(
>  81 <#l81>                "Default buffer size used in BufferedOutputStream
" +
>  82 <#l82>                 "constructor. It would be " +
>  83 <#l83>                "better to be explicit if an 8k buffer is required.");
>  84 <#l84>         // END android-added
>  85 <#l85>     }
> Java.util.logging provided a suitable vehicle for emitting a warning. We
> haven't seen any problems caused by the coupling between luni and logging
> 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 than
> the coupling it prevents.

View raw message