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 23:49:44 GMT


Nathan Beyer wrote:
> 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?

Leave them.  They don't change.

> Do we leave the public
> domain comment? Do we add the ASLv2 comment?

Don't do anything to them unless we modify them.

geir

> 
> -Nathan
> 
>> -----Original Message-----
>> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
>> 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: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
> 
> 
> ---------------------------------------------------------------------
> 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