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 Wed, 07 Jun 2006 17:20:54 GMT
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)?

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

> 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

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



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

View raw message