harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] proposal - resolution to java.util.concurrent issue
Date Sun, 11 Jun 2006 19:57:12 GMT
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> Geir Magnusson Jr wrote:
<snip>
>>>>> 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.
>>>> So I understand correctly, are you talking about taking the source code
>>>> into Harmony SVN, or creating a dependency on a binary version of that
>>>> code (stored in our SVN)?
>>> Into our SVN, simply for ease of use, oversight, and control.
>> Can you expand on that for me?  Why isn't a binary dependency sufficient?
> 
> It would be if there was one.  As far as I can tell, there isn't.

We we can build it and store the binary, like we do for ICU4JNI which
also does not have a binary available from that project.

> There also may be small mods required to work w/ our VMI.  Dunno -
> hopefully Nathan or others can tell us.

Sure, we can store required mods -- again we have precedence for that
model too.

> What's the problem with having the source around?  It makes it easier
> for people to look at, debug, etc...

See below...

What's the problem with leaving the bulk of the source where it is and
patching it there for one and all?

>>>> Just trying to figure the rationale of taking source if the goal is to
>>>> be in lock-step.  Are you imagining that there may be patches created
>>>> here that are ALv2'd only (and maybe therefore do not go back into
>>>> Doug's copy)?
>>> It could be, although given how it seems to be working, I would guess
>>> we'd work with Doug if there were problems, and see if he'd do it into
>>> the RI.
>>>
>>>>> 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.
>>>> AIUI (and hypothetically) people could take a copy of the public domain
>>>> code and create a proprietary derivative couldn't they? And the spec is
>>>> out there for all to see, how do you know there are no other
>>>> implementations?
>>> There could be implementations out there now, but there weren't before,
>>> and we'd just have to watch to see what gets added down the road...
>> I assume that the authors (jsr166-group) have a good knowledge of all
>> sorts of code that is in our ACQ CORE bucket.  The need not only be
>> 'contaminated' by concurrent.
> 
> Right, but unless you believe that by knowing about code in our CORE
> bucket that isn't j.u.c yet somehow tainted j.u.c, shouldn't we just add
> a new 'bucket' for j.u.c to solve what would then simply be a paper problem?

Ah, so this is the proposal? I hadn't until now appreciated you were
suggesting to take java.util.concurrent out of CORE and into it's own
new bucket.

>> (I would like to see this, I'm still just thinking it through).
> 
> This is a good and reasonable discussion to have.  I'm just working the
> "Pragmatic Devil's Advocate" line here...

...and I shall play the other part just so we explore all the ramifications.

Regards,
Tim

-- 

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


Mime
View raw message