Nathan Beyer wrote: > FYI - Unless someone else is already digging into it I'm going to try and > take a first swipe at getting this code setup and working with the current > build. > > How do we handle the copyright comments in the files?
Leave them. They don't change. > Do we leave the public > domain comment? Do we add the ASLv2 comment? Don't do anything to them unless we modify them. geir > > -Nathan > >> -----Original Message----- >> From: Nathan Beyer [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, June 07, 2006 6:54 PM >> To: [email protected] >> Subject: RE: [classlib] proposal - resolution to java.util.concurrent >> issue >> >>> -----Original Message----- >>> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, June 07, 2006 6:37 PM >>> To: [email protected] >>> Subject: Re: [classlib] proposal - resolution to java.util.concurrent >>> issue >>> >>> >>> >>> Nathan Beyer wrote: >>>> I'm all for it, especially if Doug is okay with it. >>> I can certainly say that Doug would prefer it. >>> >>>> I made an attempt at >>>> using the code a week back and it should be fairly easy to get the >>> majority >>>> of it in. The missing piece would be a VMI API for the atomic and lock >>>> functionality. >>> Maybe Tim/George/Mark/Oliver can give us a hint ;) It would be nice for >>> J9 to continue to work. >>> >> One way to address some of this would be to begin with just the j.u.c >> classes only; from what I could tell most if not all of them didn't have >> any >> dependencies on the atomic and lock sub packages. >> >> Also, I think we could stub out the VMI API such that other classes would >> at >> least compile. I'm not extremely familiar with the atomic APIs, but I >> think >> would could go as far to build a temporary atomicity implementation by >> using >> plain-old synchronized locks ... maybe. :) >> >>>> Would we be using the latest version from HEAD, or is there a tag we >>> should >>>> begin with? The latest code seems to have some Java 6 classes. Would >> we >>>> leave them out for now, or just leave them in? >>> There probably is a tag for the latest Java 5 version, and I'd leave >>> them out to limit confusion (and so we can use the same version that >>> Sun/IBM/BEA is using) but I don't feel strongly at all about this. >>> >>> geir >>> >>> >>>> -Nathan >>>> >>>>> -----Original Message----- >>>>> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >>>>> Sent: Wednesday, June 07, 2006 10:29 AM >>>>> To: [email protected] >>>>> Subject: [classlib] proposal - resolution to java.util.concurrent >> issue >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> Comments? Things that I missed? >>>>> >>>>> geir >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: harmony-dev- >> [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] >> >> --------------------------------------------------------------------- >> 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]
