Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 82.138.226.220 is neither permitted nor
 denied by domain of t.p.ellison@gmail.com)
Message-ID: <44B67914.9090508@gmail.com>
Date: Thu, 13 Jul 2006 17:47:16 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][concurrent] java.util.concurrent module proposal
References: <005401c6a56e$79234ce0$0c01a8c0@LITTLEGUY>
 <44B4BD6D.2020707@gmail.com> <44B4C369.2050208@pobox.com>
 <44B50D5A.9060800@gmail.com> <44B57CFE.4020208@pobox.com>
In-Reply-To: <44B57CFE.4020208@pobox.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> Geir Magnusson Jr wrote:
>>> Tim Ellison wrote:
>>>> Nathan Beyer wrote:
>>>>> I've checked in my proposal for the java.util.concurrent module at
>>>>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/s
>>>>> andbox/juc-proposal.
>>>> You didn't just check in a proposal, you also checked in
>>>> Doug Lea et al's code.  Nobody should commit other people's code into
>>>> svn this way.
>>> The code is under public domain license, so there should be no problem
>>> doing it since Doug et al produce no builds, and they suggested we do
>>> this.
>> (not trying to be provocative, just trying to understand)
>>
>> "they" = the concurrency authors?
>> "do this" = produce builds or check the code into our repository?

Did I get this right?

>>> it's also in our sandbox, and we're not redistributing it yet.
>>>
>>>> Was there a reason to create .../classlib/trunk/sandbox? wouldn't
>>>> .../classlib/sandbox make more sense?
>>> We already had the sandbox under /trunk
>> No we didn't.
>>
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/sandbox/?view=log&pathrev=421111
>>
>> Perhaps it was created in the trunk by mistake.
> 
> Oh, right.  Sorry - there was a sandbox in enhanced/trunk which is what
> I thought it was checked into...

So does anyone object to the proposed code being moved out of the
enhanced subtree while we stare at it, thereby preserving our definition
of 'enhanced'.

>>>> I see copying the code as a one-way operation.  We can hope to track
>>>> updates to the original code thoroughly, but I don't see any fixes made
>>>> in Harmony making it back directly into Doug's repository.
>>> Why not?  We just offer them to Doug, and he can accept or reject.
>> It strikes me as a strange model.  If there is a well-run, active
>> project with compatible license elsewhere I'm struggling to see why we
>> would not just join in there, and all enjoy the fruits of the combined
>> work <g>.  Maybe this was discussed as part of the suggestion from Doug?
> 
> Doug just suggested that we'd be well served using his code since it's
> public domain and the definitive implementation.
> 
> If there is a well-run, active project with compatible license
> elsewhere, please point it out.  As far as I know, this is the only
> implementation out there, and is why it's taken and used by IBM, BEA,
> Apple and Sun in the same way we're proposing.

(IBM does not source the code directly from there, but that is a
different matter)

> Why not just "enjoy the fruits" of what's being offered as public domain
> by arguably the world's top expert on the subject?  While we have lots
> of talent around here, I'd be very surprised if we could do better.

No arguments from me, that was the point that I was making too.  Let's
work with that project where we need to do so, and take their code as a
dependency for Harmony.

>>>> Is there a reason why we want to fork this code?  I'd rather we worked
>>>> with Doug (contributing directly to his project to make it more widely
>>>> usable etc).
>>> Tim, isn't this what we discussed? This isn't a fork in the community
>>> sense, it's what amounts to a "read only" copy of the code for purposes
>>> of building, but tracking what Doug does?  We've been very clear about that.
>> Do you think it is reasonable to work with that group to make the code
>> usable by Harmony as well as Sun?
>>
> 
> Yes, of course, although it seems usable now...

Not without the modifications that nathan has been working on.

>> I guess the alternative is that we replicate Sun's internal APIs if we
>> want to make the incoming code read-only (and presumably put it into the
>> depends/ directory).
> 
> I don't understand the bit about the depends directory, but yes, I think
> that using this code as-is would require us to implement
> sun.misc.Unsafe, and I do think it's a reasonable thing to suggest to
> Doug that a neutral package is chosen for this....  like
> "org.apache.harmony.Unsafe" :)

Now we are talking ;-)  In fact, if Sun want to publish the API I'm even
prepared to give up the o.a.h. bit <g>

<snip>

>>>>> * Determine the best place to integrate the TCK source, which is also
>>>>> available at Doug Lea's site.
>>>> Are you serious?  Why would we copy the TCK into Harmony too?!
>>> Because that isn't the TCK, but simply testcases?
>> I haven't checked, I took Nathan at his word.
> 
> They are labeled as TCK tests, but by definition, the TCK only comes
> from the Spec lead.
> 
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/
> 
> So from our POV, while this is code that is used in the TCK, it's not
> the TCK, and if we accept the public domain terms, we should be free to
> use them to augment our test suite.

I agree (modulo the general 'taking code' discussion underway).

<snip>

>> I thought we were trying to reach a conclusion which is why I was
>> surprised to see the code appear.
> 
> We are still trying to reach a conclusion, actually two of them - the
> techincal conclusion, and the process/legal one.
> 
> I think having the code around to stare at will make the technical
> conclusion easier (and my first comment is that we shouldn't be
> modifying Doug' stuff, even just to change package name of atomic support).

The code has always been around, but whatever.  If having it local helps
then I'm fine with it being in the standard area of the repository for
reference.

Perhaps we should have the discussion about modifying the concurrency
code for interaction with the VM / class library over on the
concurrency-interest list?

> At the same time, we can resolve the legal/process issues...

Yep.  if we decide that we can take an unmodified binary-only then this
becomes much simpler too; but that is undecided as yet.

p.s. I'm logging off for ~4 days so will be quiet for a bit.

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