harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib] proposal - resolution to java.util.concurrent issue
Date Thu, 08 Jun 2006 00:36:45 GMT


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.

> 
> 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


Mime
View raw message