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][concurrent] java.util.concurrent module proposal
Date Sun, 16 Jul 2006 23:48:19 GMT


Nathan Beyer wrote:
> Resulting actions:
> * Move code to the 'standard' folder? (I'll do this in the next few days if
> there aren't any complaints)

Sure. It's just a proposal at this point anyway.  Things to think about
though will be if we choose this route (and I see no reason why not)
then how do we integrate it into the build?

Given it's really just an external dependency that we have a copy of the
code for (and create a jar), then maybe it's at first simply go into
/standard, do an 'ant jar', and then copy the dep jar over.  Later we
can integrate in to the top-level dependency area.

Assuming we do this, the com.misc.Unsafe code *will* be in /enhanced
somewhere as that is our code and in theory clean.

> * Continue with proposal code, create a prototype and try to work with the
> concurrency group.

The only thing I could see us doing w/ the 166 EG right now is to offer
them back a clean-room copy of CopyOnWriteArrayList since we have to
implement it (in /enhanced), to replace the proprietary Sun version
that's there.

> 
> Any other major items?

Well, implement com.misc.Unsafe. :) Also,  I'm getting a note from Doug
to see if that satisfies the various constituencies.  I'll post that
once that's done.

geir

> 
> -Nathan
> 
>> -----Original Message-----
>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>> Sent: Thursday, July 13, 2006 12:03 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib][concurrent] java.util.concurrent module proposal
>>
>>
>>
>> Tim Ellison wrote:
>>> 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?
>> Sorry - I missed this - "they" really was Doug, and "do this" is "take
>> the code".  Checking it in simply is good practice for peace of mind.
>>
>>>>>> 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/san
>> dbox/?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 sort of do because we are utterly inconsistent about this, but if you
>> look at my other message, if we just shove this into /standard/ the
>> whole problem seems to magically go away anyway, so go ahead.
>>
>>
>>>>>>> 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.
>> That's what we're doing.
>>
>>>>>>> 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.
>> We want to avoid modifying their code.
>>
>>>>> 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>
>> That works for me too, although the joy of seeing "harmony" in a Sun VM
>> package dep would be a hoot...
>>
>>> <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?
>> That's very reasonable, but I think that getting it to work as a proto
>> using the work that Nathan as done and other help would be beneficial,
>> as we can then go to them with working code and a good argument as to
>> why they need to do this.
>>
>>>> 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
>>>
>> ---------------------------------------------------------------------
>> 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