harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [classlib][concurrent] java.util.concurrent module proposal
Date Fri, 14 Jul 2006 02:14:36 GMT
Resulting actions:
* Move code to the 'standard' folder? (I'll do this in the next few days if
there aren't any complaints)
* Continue with proposal code, create a prototype and try to work with the
concurrency group.

Any other major items?

-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


Mime
View raw message