Nathan Beyer wrote: > Resulting actions: > * Move code to the 'standard' folder? (I'll do this in the next few days if > there aren't any complaints)
Sure. It's just a proposal at this point anyway. Things to think about though will be if we choose this route (and I see no reason why not) then how do we integrate it into the build? Given it's really just an external dependency that we have a copy of the code for (and create a jar), then maybe it's at first simply go into /standard, do an 'ant jar', and then copy the dep jar over. Later we can integrate in to the top-level dependency area. Assuming we do this, the com.misc.Unsafe code *will* be in /enhanced somewhere as that is our code and in theory clean. > * Continue with proposal code, create a prototype and try to work with the > concurrency group. The only thing I could see us doing w/ the 166 EG right now is to offer them back a clean-room copy of CopyOnWriteArrayList since we have to implement it (in /enhanced), to replace the proprietary Sun version that's there. > > Any other major items? Well, implement com.misc.Unsafe. :) Also, I'm getting a note from Doug to see if that satisfies the various constituencies. I'll post that once that's done. geir > > -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] > > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
