harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [classlib] proposal - resolution to java.util.concurrent issue
Date Thu, 08 Jun 2006 00:53:49 GMT
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> 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:geir@pobox.com]
> >> 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: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message