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. > > 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... 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]
