> -----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: [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]
