You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/06/07 18:28:30 UTC
[classlib] proposal - resolution to java.util.concurrent issue
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.
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.
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.
Comments? Things that I missed?
geir
---------------------------------------------------------------------
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
Re: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> Geir Magnusson Jr wrote:
<snip>
>>>>> 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.
We we can build it and store the binary, like we do for ICU4JNI which
also does not have a binary available from that project.
> There also may be small mods required to work w/ our VMI. Dunno -
> hopefully Nathan or others can tell us.
Sure, we can store required mods -- again we have precedence for that
model too.
> What's the problem with having the source around? It makes it easier
> for people to look at, debug, etc...
See below...
What's the problem with leaving the bulk of the source where it is and
patching it there for one and all?
>>>> 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?
Ah, so this is the proposal? I hadn't until now appreciated you were
suggesting to take java.util.concurrent out of CORE and into it's own
new bucket.
>> (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...
...and I shall play the other part just so we explore all the ramifications.
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
Re: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Nathan Beyer wrote:
>
>> -----Original Message-----
>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>> Tim Ellison wrote:
>>> Geir Magnusson Jr wrote:
>>>> Tim Ellison wrote:
>>> 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.
>>
> There was one binary, but it seemed more like an experimental build of new
> stuff.
Right - my impression is that Doug and crew are not in the business to
be providing distributions of this code, given the limited audience (us,
Sun, IBM, BEA and GNU Classpath) and the need for it to be tweaked for
each usage.
>
> As for the code, there will have to be some modifications to work with our
> VMI. The java.util.concurrent classes are clean, but the 'atomic' and
> 'locks' packages are filled with references to a Sun proprietary class, that
> we would have to replace. For example, check out the AtomicBoolean class
> [1].
>
> [1]
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu
> rrent/atomic/AtomicBoolean.java?rev=1.20&content-type=text/vnd.viewcvs-marku
> p
>
Thanks
geir
---------------------------------------------------------------------
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
RE: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Nathan Beyer <nb...@kc.rr.com>.
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> 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.
>
There was one binary, but it seemed more like an experimental build of new
stuff.
As for the code, there will have to be some modifications to work with our
VMI. The java.util.concurrent classes are clean, but the 'atomic' and
'locks' packages are filled with references to a Sun proprietary class, that
we would have to replace. For example, check out the AtomicBoolean class
[1].
[1]
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu
rrent/atomic/AtomicBoolean.java?rev=1.20&content-type=text/vnd.viewcvs-marku
p
> 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
---------------------------------------------------------------------
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
Re: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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
Re: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Tim Ellison <t....@gmail.com>.
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?
>> 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.
(I would like to see this, I'm still just thinking it through).
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
>
>
--
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
Re: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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.
>
> 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...
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
Re: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Tim Ellison <t....@gmail.com>.
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
implementations?
> 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>.
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
Re: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
>
> Nathan Beyer wrote:
>> I'm all for it, especially if Doug is okay with it.
>
> I can certainly say that Doug would prefer it.
>
>> I made an attempt at
>> using the code a week back and it should be fairly easy to get the majority
>> of it in. The missing piece would be a VMI API for the atomic and lock
>> functionality.
>
> Maybe Tim/George/Mark/Oliver can give us a hint ;) It would be nice for
> J9 to continue to work.
Sure, it would require we switch to a 1.5 VM, but that is not a bad
thing (and warrants another thread).
Regards,
Tim
>> Would we be using the latest version from HEAD, or is there a tag we should
>> begin with? The latest code seems to have some Java 6 classes. Would we
>> leave them out for now, or just leave them in?
>
> There probably is a tag for the latest Java 5 version, and I'd leave
> them out to limit confusion (and so we can use the same version that
> Sun/IBM/BEA is using) but I don't feel strongly at all about this.
>
> geir
>
>
>> -Nathan
>>
>>> -----Original Message-----
>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>> Sent: Wednesday, June 07, 2006 10:29 AM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: [classlib] proposal - resolution to java.util.concurrent issue
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Comments? Things that I missed?
>>>
>>> geir
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
--
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
Re: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Geir Magnusson Jr <ge...@pobox.com>.
What we'll do if we accept this is fix at that time. I'm saying "don't
do much" now because
1) get it working but don't commit yet because we don't have consensus
on this
2) There may be a change in how copyright and license headers are done,
so if that happens before we accept this, we can use the new way
geir
Geir Magnusson Jr wrote:
>
> Nathan Beyer wrote:
>> FYI - Unless someone else is already digging into it I'm going to try and
>> take a first swipe at getting this code setup and working with the current
>> build.
>>
>> How do we handle the copyright comments in the files?
>
> Leave them. They don't change.
>
>> Do we leave the public
>> domain comment? Do we add the ASLv2 comment?
>
> Don't do anything to them unless we modify them.
>
> geir
>
>> -Nathan
>>
>>> -----Original Message-----
>>> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
>>> Sent: Wednesday, June 07, 2006 6:54 PM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: RE: [classlib] proposal - resolution to java.util.concurrent
>>> issue
>>>
>>>> -----Original Message-----
>>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>>> Sent: Wednesday, June 07, 2006 6:37 PM
>>>> To: harmony-dev@incubator.apache.org
>>>> Subject: Re: [classlib] proposal - resolution to java.util.concurrent
>>>> issue
>>>>
>>>>
>>>>
>>>> Nathan Beyer wrote:
>>>>> I'm all for it, especially if Doug is okay with it.
>>>> I can certainly say that Doug would prefer it.
>>>>
>>>>> I made an attempt at
>>>>> using the code a week back and it should be fairly easy to get the
>>>> majority
>>>>> of it in. The missing piece would be a VMI API for the atomic and lock
>>>>> functionality.
>>>> Maybe Tim/George/Mark/Oliver can give us a hint ;) It would be nice for
>>>> J9 to continue to work.
>>>>
>>> One way to address some of this would be to begin with just the j.u.c
>>> classes only; from what I could tell most if not all of them didn't have
>>> any
>>> dependencies on the atomic and lock sub packages.
>>>
>>> Also, I think we could stub out the VMI API such that other classes would
>>> at
>>> least compile. I'm not extremely familiar with the atomic APIs, but I
>>> think
>>> would could go as far to build a temporary atomicity implementation by
>>> using
>>> plain-old synchronized locks ... maybe. :)
>>>
>>>>> Would we be using the latest version from HEAD, or is there a tag we
>>>> should
>>>>> begin with? The latest code seems to have some Java 6 classes. Would
>>> we
>>>>> leave them out for now, or just leave them in?
>>>> There probably is a tag for the latest Java 5 version, and I'd leave
>>>> them out to limit confusion (and so we can use the same version that
>>>> Sun/IBM/BEA is using) but I don't feel strongly at all about this.
>>>>
>>>> geir
>>>>
>>>>
>>>>> -Nathan
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>>>>> Sent: Wednesday, June 07, 2006 10:29 AM
>>>>>> To: harmony-dev@incubator.apache.org
>>>>>> Subject: [classlib] proposal - resolution to java.util.concurrent
>>> issue
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Comments? Things that I missed?
>>>>>>
>>>>>> geir
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
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
Re: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Nathan Beyer wrote:
> FYI - Unless someone else is already digging into it I'm going to try and
> take a first swipe at getting this code setup and working with the current
> build.
>
> How do we handle the copyright comments in the files?
Leave them. They don't change.
> Do we leave the public
> domain comment? Do we add the ASLv2 comment?
Don't do anything to them unless we modify them.
geir
>
> -Nathan
>
>> -----Original Message-----
>> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
>> Sent: Wednesday, June 07, 2006 6:54 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: RE: [classlib] proposal - resolution to java.util.concurrent
>> issue
>>
>>> -----Original Message-----
>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>> Sent: Wednesday, June 07, 2006 6:37 PM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: Re: [classlib] proposal - resolution to java.util.concurrent
>>> issue
>>>
>>>
>>>
>>> Nathan Beyer wrote:
>>>> I'm all for it, especially if Doug is okay with it.
>>> I can certainly say that Doug would prefer it.
>>>
>>>> I made an attempt at
>>>> using the code a week back and it should be fairly easy to get the
>>> majority
>>>> of it in. The missing piece would be a VMI API for the atomic and lock
>>>> functionality.
>>> Maybe Tim/George/Mark/Oliver can give us a hint ;) It would be nice for
>>> J9 to continue to work.
>>>
>> One way to address some of this would be to begin with just the j.u.c
>> classes only; from what I could tell most if not all of them didn't have
>> any
>> dependencies on the atomic and lock sub packages.
>>
>> Also, I think we could stub out the VMI API such that other classes would
>> at
>> least compile. I'm not extremely familiar with the atomic APIs, but I
>> think
>> would could go as far to build a temporary atomicity implementation by
>> using
>> plain-old synchronized locks ... maybe. :)
>>
>>>> Would we be using the latest version from HEAD, or is there a tag we
>>> should
>>>> begin with? The latest code seems to have some Java 6 classes. Would
>> we
>>>> leave them out for now, or just leave them in?
>>> There probably is a tag for the latest Java 5 version, and I'd leave
>>> them out to limit confusion (and so we can use the same version that
>>> Sun/IBM/BEA is using) but I don't feel strongly at all about this.
>>>
>>> geir
>>>
>>>
>>>> -Nathan
>>>>
>>>>> -----Original Message-----
>>>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>>>> Sent: Wednesday, June 07, 2006 10:29 AM
>>>>> To: harmony-dev@incubator.apache.org
>>>>> Subject: [classlib] proposal - resolution to java.util.concurrent
>> issue
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> Comments? Things that I missed?
>>>>>
>>>>> geir
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>> ---------------------------------------------------------------------
>> 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
RE: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Nathan Beyer <nb...@kc.rr.com>.
FYI - Unless someone else is already digging into it I'm going to try and
take a first swipe at getting this code setup and working with the current
build.
How do we handle the copyright comments in the files? Do we leave the public
domain comment? Do we add the ASLv2 comment?
-Nathan
> -----Original Message-----
> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
> Sent: Wednesday, June 07, 2006 6:54 PM
> To: harmony-dev@incubator.apache.org
> Subject: RE: [classlib] proposal - resolution to java.util.concurrent
> issue
>
> > -----Original Message-----
> > From: Geir Magnusson Jr [mailto:geir@pobox.com]
> > Sent: Wednesday, June 07, 2006 6:37 PM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [classlib] proposal - resolution to java.util.concurrent
> > issue
> >
> >
> >
> > Nathan Beyer wrote:
> > > I'm all for it, especially if Doug is okay with it.
> >
> > I can certainly say that Doug would prefer it.
> >
> > > I made an attempt at
> > > using the code a week back and it should be fairly easy to get the
> > majority
> > > of it in. The missing piece would be a VMI API for the atomic and lock
> > > functionality.
> >
> > Maybe Tim/George/Mark/Oliver can give us a hint ;) It would be nice for
> > J9 to continue to work.
> >
> One way to address some of this would be to begin with just the j.u.c
> classes only; from what I could tell most if not all of them didn't have
> any
> dependencies on the atomic and lock sub packages.
>
> Also, I think we could stub out the VMI API such that other classes would
> at
> least compile. I'm not extremely familiar with the atomic APIs, but I
> think
> would could go as far to build a temporary atomicity implementation by
> using
> plain-old synchronized locks ... maybe. :)
>
> > >
> > > Would we be using the latest version from HEAD, or is there a tag we
> > should
> > > begin with? The latest code seems to have some Java 6 classes. Would
> we
> > > leave them out for now, or just leave them in?
> >
> > There probably is a tag for the latest Java 5 version, and I'd leave
> > them out to limit confusion (and so we can use the same version that
> > Sun/IBM/BEA is using) but I don't feel strongly at all about this.
> >
> > geir
> >
> >
> > >
> > > -Nathan
> > >
> > >> -----Original Message-----
> > >> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> > >> Sent: Wednesday, June 07, 2006 10:29 AM
> > >> To: harmony-dev@incubator.apache.org
> > >> Subject: [classlib] proposal - resolution to java.util.concurrent
> issue
> > >>
> > >> 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.
> > >>
> > >> 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.
> > >>
> > >> 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.
> > >>
> > >> Comments? Things that I missed?
> > >>
> > >> geir
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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
>
>
> ---------------------------------------------------------------------
> 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
RE: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Nathan Beyer <nb...@kc.rr.com>.
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> Sent: Wednesday, June 07, 2006 6:37 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib] proposal - resolution to java.util.concurrent
> issue
>
>
>
> Nathan Beyer wrote:
> > I'm all for it, especially if Doug is okay with it.
>
> I can certainly say that Doug would prefer it.
>
> > I made an attempt at
> > using the code a week back and it should be fairly easy to get the
> majority
> > of it in. The missing piece would be a VMI API for the atomic and lock
> > functionality.
>
> Maybe Tim/George/Mark/Oliver can give us a hint ;) It would be nice for
> J9 to continue to work.
>
One way to address some of this would be to begin with just the j.u.c
classes only; from what I could tell most if not all of them didn't have any
dependencies on the atomic and lock sub packages.
Also, I think we could stub out the VMI API such that other classes would at
least compile. I'm not extremely familiar with the atomic APIs, but I think
would could go as far to build a temporary atomicity implementation by using
plain-old synchronized locks ... maybe. :)
> >
> > Would we be using the latest version from HEAD, or is there a tag we
> should
> > begin with? The latest code seems to have some Java 6 classes. Would we
> > leave them out for now, or just leave them in?
>
> There probably is a tag for the latest Java 5 version, and I'd leave
> them out to limit confusion (and so we can use the same version that
> Sun/IBM/BEA is using) but I don't feel strongly at all about this.
>
> geir
>
>
> >
> > -Nathan
> >
> >> -----Original Message-----
> >> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> >> Sent: Wednesday, June 07, 2006 10:29 AM
> >> To: harmony-dev@incubator.apache.org
> >> Subject: [classlib] proposal - resolution to java.util.concurrent issue
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> Comments? Things that I missed?
> >>
> >> geir
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
---------------------------------------------------------------------
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
Re: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Nathan Beyer wrote:
> I'm all for it, especially if Doug is okay with it.
I can certainly say that Doug would prefer it.
> I made an attempt at
> using the code a week back and it should be fairly easy to get the majority
> of it in. The missing piece would be a VMI API for the atomic and lock
> functionality.
Maybe Tim/George/Mark/Oliver can give us a hint ;) It would be nice for
J9 to continue to work.
>
> Would we be using the latest version from HEAD, or is there a tag we should
> begin with? The latest code seems to have some Java 6 classes. Would we
> leave them out for now, or just leave them in?
There probably is a tag for the latest Java 5 version, and I'd leave
them out to limit confusion (and so we can use the same version that
Sun/IBM/BEA is using) but I don't feel strongly at all about this.
geir
>
> -Nathan
>
>> -----Original Message-----
>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>> Sent: Wednesday, June 07, 2006 10:29 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: [classlib] proposal - resolution to java.util.concurrent issue
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Comments? Things that I missed?
>>
>> geir
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
RE: [classlib] proposal - resolution to java.util.concurrent issue
Posted by Nathan Beyer <nb...@kc.rr.com>.
I'm all for it, especially if Doug is okay with it. I made an attempt at
using the code a week back and it should be fairly easy to get the majority
of it in. The missing piece would be a VMI API for the atomic and lock
functionality.
Would we be using the latest version from HEAD, or is there a tag we should
begin with? The latest code seems to have some Java 6 classes. Would we
leave them out for now, or just leave them in?
-Nathan
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> Sent: Wednesday, June 07, 2006 10:29 AM
> To: harmony-dev@incubator.apache.org
> Subject: [classlib] proposal - resolution to java.util.concurrent issue
>
> 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.
>
> 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.
>
> 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.
>
> Comments? Things that I missed?
>
> geir
>
>
>
> ---------------------------------------------------------------------
> 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