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 Fri, 09 Jun 2006 10:26:43 GMT


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

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

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

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

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

geir

> 
> Regards,
> Tim
> 
>> That is the gate I was talking about - we are still overseeing what
>> we're distributing...
>>
>>
>>>> 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.
>>> Don't get me wrong, I think we should build the bridge -- just working
>>> things out in my head.
>>>
>>>> Comments? Things that I missed?
>>> Invite the j.u.concurrent expert group to move in <g>.
>> That would be cool :)
>>
>> geir
>>
>>> Regards,
>>> Tim
>>>
>> ---------------------------------------------------------------------
>> 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