On 10/Nov/2009 03:52, Nathan Beyer wrote: > On Mon, Nov 9, 2009 at 4:31 PM, Jesse Wilson <jessewil...@google.com> wrote: >> 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. > > 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 already mooted the point earlier this year, http://markmail.org/thread/4kf7zlz2qujuemxw There was general approval so if you want to take a crack at it, go ahead. Regards, Tim > 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. >> >
