Resulting actions: * Move code to the 'standard' folder? (I'll do this in the next few days if there aren't any complaints) * Continue with proposal code, create a prototype and try to work with the concurrency group.
Any other major items? -Nathan > -----Original Message----- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 13, 2006 12:03 PM > To: harmony-dev@incubator.apache.org > Subject: Re: [classlib][concurrent] java.util.concurrent module proposal > > > > Tim Ellison wrote: > > Geir Magnusson Jr wrote: > >> Tim Ellison wrote: > >>> Geir Magnusson Jr wrote: > >>>> Tim Ellison wrote: > >>>>> Nathan Beyer wrote: > >>>>>> I've checked in my proposal for the java.util.concurrent module at > >>>>>> > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk > /s > >>>>>> andbox/juc-proposal. > >>>>> You didn't just check in a proposal, you also checked in > >>>>> Doug Lea et al's code. Nobody should commit other people's code > into > >>>>> svn this way. > >>>> The code is under public domain license, so there should be no > problem > >>>> doing it since Doug et al produce no builds, and they suggested we do > >>>> this. > >>> (not trying to be provocative, just trying to understand) > >>> > >>> "they" = the concurrency authors? > >>> "do this" = produce builds or check the code into our repository? > > > > Did I get this right? > > Sorry - I missed this - "they" really was Doug, and "do this" is "take > the code". Checking it in simply is good practice for peace of mind. > > > > >>>> it's also in our sandbox, and we're not redistributing it yet. > >>>> > >>>>> Was there a reason to create .../classlib/trunk/sandbox? wouldn't > >>>>> .../classlib/sandbox make more sense? > >>>> We already had the sandbox under /trunk > >>> No we didn't. > >>> > >>> > http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/san > dbox/?view=log&pathrev=421111 > >>> > >>> Perhaps it was created in the trunk by mistake. > >> Oh, right. Sorry - there was a sandbox in enhanced/trunk which is what > >> I thought it was checked into... > > > > So does anyone object to the proposed code being moved out of the > > enhanced subtree while we stare at it, thereby preserving our definition > > of 'enhanced'. > > I sort of do because we are utterly inconsistent about this, but if you > look at my other message, if we just shove this into /standard/ the > whole problem seems to magically go away anyway, so go ahead. > > > > > >>>>> I see copying the code as a one-way operation. We can hope to track > >>>>> updates to the original code thoroughly, but I don't see any fixes > made > >>>>> in Harmony making it back directly into Doug's repository. > >>>> Why not? We just offer them to Doug, and he can accept or reject. > >>> It strikes me as a strange model. If there is a well-run, active > >>> project with compatible license elsewhere I'm struggling to see why we > >>> would not just join in there, and all enjoy the fruits of the combined > >>> work <g>. Maybe this was discussed as part of the suggestion from > Doug? > >> Doug just suggested that we'd be well served using his code since it's > >> public domain and the definitive implementation. > >> > >> If there is a well-run, active project with compatible license > >> elsewhere, please point it out. As far as I know, this is the only > >> implementation out there, and is why it's taken and used by IBM, BEA, > >> Apple and Sun in the same way we're proposing. > > > > (IBM does not source the code directly from there, but that is a > > different matter) > > > >> Why not just "enjoy the fruits" of what's being offered as public > domain > >> by arguably the world's top expert on the subject? While we have lots > >> of talent around here, I'd be very surprised if we could do better. > > > > No arguments from me, that was the point that I was making too. Let's > > work with that project where we need to do so, and take their code as a > > dependency for Harmony. > > That's what we're doing. > > > > >>>>> Is there a reason why we want to fork this code? I'd rather we > worked > >>>>> with Doug (contributing directly to his project to make it more > widely > >>>>> usable etc). > >>>> Tim, isn't this what we discussed? This isn't a fork in the community > >>>> sense, it's what amounts to a "read only" copy of the code for > purposes > >>>> of building, but tracking what Doug does? We've been very clear > about that. > >>> Do you think it is reasonable to work with that group to make the code > >>> usable by Harmony as well as Sun? > >>> > >> Yes, of course, although it seems usable now... > > > > Not without the modifications that nathan has been working on. > > We want to avoid modifying their code. > > > > >>> I guess the alternative is that we replicate Sun's internal APIs if we > >>> want to make the incoming code read-only (and presumably put it into > the > >>> depends/ directory). > >> I don't understand the bit about the depends directory, but yes, I > think > >> that using this code as-is would require us to implement > >> sun.misc.Unsafe, and I do think it's a reasonable thing to suggest to > >> Doug that a neutral package is chosen for this.... like > >> "org.apache.harmony.Unsafe" :) > > > > Now we are talking ;-) In fact, if Sun want to publish the API I'm even > > prepared to give up the o.a.h. bit <g> > > That works for me too, although the joy of seeing "harmony" in a Sun VM > package dep would be a hoot... > > > > > <snip> > > > >>>>>> * Determine the best place to integrate the TCK source, which is > also > >>>>>> available at Doug Lea's site. > >>>>> Are you serious? Why would we copy the TCK into Harmony too?! > >>>> Because that isn't the TCK, but simply testcases? > >>> I haven't checked, I took Nathan at his word. > >> They are labeled as TCK tests, but by definition, the TCK only comes > >> from the Spec lead. > >> > >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ > >> > >> So from our POV, while this is code that is used in the TCK, it's not > >> the TCK, and if we accept the public domain terms, we should be free to > >> use them to augment our test suite. > > > > I agree (modulo the general 'taking code' discussion underway). > > > > <snip> > > > >>> I thought we were trying to reach a conclusion which is why I was > >>> surprised to see the code appear. > >> We are still trying to reach a conclusion, actually two of them - the > >> techincal conclusion, and the process/legal one. > >> > >> I think having the code around to stare at will make the technical > >> conclusion easier (and my first comment is that we shouldn't be > >> modifying Doug' stuff, even just to change package name of atomic > support). > > > > The code has always been around, but whatever. If having it local helps > > then I'm fine with it being in the standard area of the repository for > > reference. > > > > Perhaps we should have the discussion about modifying the concurrency > > code for interaction with the VM / class library over on the > > concurrency-interest list? > > That's very reasonable, but I think that getting it to work as a proto > using the work that Nathan as done and other help would be beneficial, > as we can then go to them with working code and a good argument as to > why they need to do this. > > > > >> At the same time, we can resolve the legal/process issues... > > > > Yep. if we decide that we can take an unmodified binary-only then this > > becomes much simpler too; but that is undecided as yet. > > > > p.s. I'm logging off for ~4 days so will be quiet for a bit. > > > > 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]
