Tim Ellison wrote: > 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?
It would be if there was one. As far as I can tell, there isn't. There also may be small mods required to work w/ our VMI. Dunno - hopefully Nathan or others can tell us. What's the problem with having the source around? It makes it easier for people to look at, debug, etc... > >>> 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? > > (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... geir > > 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] >> >> > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
