Geir Magnusson Jr wrote: > > Tim Ellison wrote: >> Geir Magnusson Jr wrote: >>> I had a nice chat with Doug today to try to reach a conclusion regarding >>> j.u.c >>> >>> Given that everyone else (Sun, IBM, BEA...) seems to use j.u.c, found here >>> >>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ >>> >>> I think that we'd be well-served to do so as well. It's the RI, it's >>> complicated, it goes w/o saying that Doug is committed to this being >>> right, and I'd like to have the same bugs as everyone else for now :) >>> >>> 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? >> 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. (I would like to see this, I'm still just thinking it through). Regards, Tim > That is the gate I was talking about - we are still overseeing what > we're distributing... > > >>> Of course, this needs VM support, so there is work to do, but this seems >>> like a sane and clean way to add this functionality to Harmony classlib, >>> as well as build a bridge to another part of the Java SE ecosystem. >> Don't get me wrong, I think we should build the bridge -- just working >> things out in my head. >> >>> Comments? Things that I missed? >> Invite the j.u.concurrent expert group to move in <g>. > > That would be cool :) > > geir > >> Regards, >> Tim >> > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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]
