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? Do we leave the public domain comment? Do we add the ASLv2 comment? -Nathan > -----Original Message----- > From: Nathan Beyer [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 07, 2006 6:54 PM > To: harmony-dev@incubator.apache.org > 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: harmony-dev@incubator.apache.org > > 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: harmony-dev@incubator.apache.org > > >> 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]
