On Mon, Nov 9, 2009 at 4:14 AM, Tim Ellison <t.p.elli...@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. 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.
