> -----Original Message----- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > 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. > There was one binary, but it seemed more like an experimental build of new stuff.
As for the code, there will have to be some modifications to work with our VMI. The java.util.concurrent classes are clean, but the 'atomic' and 'locks' packages are filled with references to a Sun proprietary class, that we would have to replace. For example, check out the AtomicBoolean class [1]. [1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu rrent/atomic/AtomicBoolean.java?rev=1.20&content-type=text/vnd.viewcvs-marku p > 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] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
