Geir Magnusson Jr wrote: > Tim Ellison wrote: >> Geir Magnusson Jr wrote: <snip> >>>>> The summary of what I think we should do is simple - we take the code >>>>> from j.u.c from the above link (w/ 1 exception) into our SVN repo and >>>>> track any changes made by Doug and the jsr166 EG going forward. >>>> So I understand correctly, are you talking about taking the source code >>>> into Harmony SVN, or creating a dependency on a binary version of that >>>> code (stored in our SVN)? >>> Into our SVN, simply for ease of use, oversight, and control. >> Can you expand on that for me? Why isn't a binary dependency sufficient? > > It would be if there was one. As far as I can tell, there isn't.
We we can build it and store the binary, like we do for ICU4JNI which also does not have a binary available from that project. > There also may be small mods required to work w/ our VMI. Dunno - > hopefully Nathan or others can tell us. Sure, we can store required mods -- again we have precedence for that model too. > What's the problem with having the source around? It makes it easier > for people to look at, debug, etc... See below... What's the problem with leaving the bulk of the source where it is and patching it there for one and all? >>>> Just trying to figure the rationale of taking source if the goal is to >>>> be in lock-step. Are you imagining that there may be patches created >>>> here that are ALv2'd only (and maybe therefore do not go back into >>>> Doug's copy)? >>> It could be, although given how it seems to be working, I would guess >>> we'd work with Doug if there were problems, and see if he'd do it into >>> the RI. >>> >>>>> All the code is under the following terms, which are acceptable to the >>>>> ASF : >>>>> >>>>> /* >>>>> * Written by Doug Lea with assistance from members of JCP JSR-166 >>>>> * Expert Group and released to the public domain, as explained at >>>>> * http://creativecommons.org/licenses/publicdomain >>>>> */ >>>>> >>>>> except for one file : >>>>> >>>>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java >>>>> >>>>> for which I understand we can get a clean replacement from the backport. >>>>> >>>>> Now, there is an issue of our clean-room rules, and I think there's a >>>>> very neat solution that would allow us to use this code w/o getting an >>>>> ACQ from the authors of j.u.c (which Doug claims is himself, assisted by >>>>> the JSR166 EG) >>>>> >>>>> The premise of our ACQ structure is that we want to ensure that people >>>>> who have worked on a non-open/non-free implementation of a >>>>> portion/module/component of Java not work on our implementation of that >>>>> portion/module/component. >>>>> >>>>> Now, given that j.u.c in Java SE 5 is the first time this functionality >>>>> has existed, it must be the case that the contributors are not >>>>> contaminated by working on another implementation, since there are no >>>>> other implementations. We can't be contaminated because there's nothing >>>>> with which to contaminate us with. >>>> AIUI (and hypothetically) people could take a copy of the public domain >>>> code and create a proprietary derivative couldn't they? And the spec is >>>> out there for all to see, how do you know there are no other >>>> implementations? >>> There could be implementations out there now, but there weren't before, >>> and we'd just have to watch to see what gets added down the road... >> I assume that the authors (jsr166-group) have a good knowledge of all >> sorts of code that is in our ACQ CORE bucket. The need not only be >> 'contaminated' by concurrent. > > Right, but unless you believe that by knowing about code in our CORE > bucket that isn't j.u.c yet somehow tainted j.u.c, shouldn't we just add > a new 'bucket' for j.u.c to solve what would then simply be a paper problem? Ah, so this is the proposal? I hadn't until now appreciated you were suggesting to take java.util.concurrent out of CORE and into it's own new bucket. >> (I would like to see this, I'm still just thinking it through). > > This is a good and reasonable discussion to have. I'm just working the > "Pragmatic Devil's Advocate" line here... ...and I shall play the other part just so we explore all the ramifications. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
