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:52:37 GMT
What we'll do if we accept this is fix at that time.  I'm saying "don't
do much" now because

1) get it working but don't commit yet because we don't have consensus
on this

2) There may be a change in how copyright and license headers are done,
so if that happens before we accept this, we can use the new way

geir


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

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