Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 82.138.226.220 is neither permitted nor
 denied by domain of t.p.ellison@gmail.com)
Message-ID: <4487B21B.9000705@gmail.com>
Date: Thu, 08 Jun 2006 06:14:03 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] proposal - resolution to java.util.concurrent issue
References: <005301c68a8c$1d3eb060$6501a8c0@OFFICEDESKTOP>
 <4487711D.5060500@pobox.com>
In-Reply-To: <4487711D.5060500@pobox.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Geir Magnusson Jr wrote:
> 
> 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.

Sure, it would require we switch to a 1.5 VM, but that is not a bad
thing (and warrants another thread).

Regards,
Tim

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

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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