You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nathan Beyer <nb...@kc.rr.com> on 2006/08/20 22:01:11 UTC
[classlib][concurrent] Integrating into builds and snapshot
Now that we're getting some good submissions to make the
java.util.concurrent code to work with DRLVM, I'd like make a proposal for
getting the code in the Class Library and a part of our regular builds,
tests and snapshots.
>From a technical/code integration standpoint, the go ahead assumption is
that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
class, such that the concurrent code, most of which is in the public domain,
from the Concurrency Interest Site [1] can be used as-is, as least to the
greatest extent possible. Are there any major dissents to this?
Now, the issue that's of most contention, at least from our past
conversations, is the code management. First and foremost, we must consider
the realities of the situation.
1. The concurrency interest group, the JSR-166 expert group, Doug Lea and
others are NOT producing distributable builds, so we can not integrate the
code like we do other components, like Xerces, Xalan, MX4J, etc. I don't
want to speak for anyone here, so I'll qualify this by saying that I haven't
been told this explicitly, so this is just my inference from discussions and
documentation. If this is not the case, then someone please speak up. There
is an experimental JAR on the site [1], but it's meant specifically to run
with the Sun RI and it contains code outside of the java.util.concurrent
package space. Additionally, the TCK tests from the site [1], which we'd
like to use are not packaged in any way.
2. The code on the site [1] is only accessible through a ViewCVS Web
interface. As such, it's not exactly easy to interact with in terms of
created an automated checkout of the source to integrate into a build. One
of my thoughts was using the svn:externals feature to download source
dynamically, but there are additional issues that make that especially
difficult; these issues follow. Besides that, I'm not sure that
svn:externals works with arbitrary URLs that aren't SVN repositories.
3. There is at least one source file that MUST NOT be used from the site [1]
because it's not open to the public domain, the CopyOnWriteArrayList [2].
This will require at least one class to be developed as part of the Harmony
Class Library.
4. It's currently NOT feasible for Harmony to use the HEAD version of the
code, as it has been updated to utilize several Java 6 APIs, which Harmony
does not current provide, not even in stub form. Additionally, there is only
one viable CVS tag (JSR166_PFD), but this tag is two years old and some of
the code in it does not compile on current JLS3 compilers. This has been
discussed on the mailing list previously; please search the archives if
you're curious. As such, any checkouts out code that compiles would have to
be done either using a date-based checkout (not really possible with
ViewCVS) or a specific revision number for each file would have to be
determined.
Tactical Proposal (next 6 to 12 to ?? months) -
My proposals for integration of the concurrency code is to retrieve the
latest possible codebase from the site [1], which is open to the public
domain and check it into our repository.
* This code would include the TCK tests.
* From a build standpoint, this code would be handled just like any other
module.
* As a general rule, this code would NOT be subject to normal code patches.
The suggested process would be to submit patches and fixes to the
concurrency interest group [1] and if/when the patches are accepted and
committed, the code can synchronized to get the updates. Upon occasion
(every few months), code updates can be take from the site [1], if deemed
necessary and appropriate.
* A minor issue is where the stub for the sun.misc.Unsafe class would be
placed (for compiles); my suggestion would be to just make it part of the
luni-kernel-stubs, but we can look at a concurrent-kernel-stubs JAR.
Strategic Proposal -
Once we have code working, at least in a snapshot state, we can attempt to
do a number of this to ease the process and discrepancies.
* Once a CopyOnWriteArrayList implementation is completed, we can submit it
back to the concurrency group for inclusion.
* Design and propose an alternate "Unsafe" service interface that can be
submitted to the concurrency interest group for use by all VMs and Class
Libraries.
Unless there are any substantial objections, with practical and workable
alternative solutions, I plan on moving forward with this approach next
weekend.
Thanks,
-Nathan Beyer
[1] http://gee.cs.oswego.edu/dl/concurrency-interest/
[2]
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu
rrent/CopyOnWriteArrayList.java?rev=HEAD&content-type=text/vnd.viewcvs-marku
p
Re: [classlib][concurrent] Integrating into builds and snapshot
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Weldon Washburn wrote:
> On 8/21/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>
>> Nathan Beyer wrote:
>> > Now that we're getting some good submissions to make the
>> > java.util.concurrent code to work with DRLVM, I'd like make a
>> proposal for
>> > getting the code in the Class Library and a part of our regular builds,
>> > tests and snapshots.
>> >
>> >
>> >
>> >>From a technical/code integration standpoint, the go ahead
>> assumption is
>> > that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
>> > class, such that the concurrent code, most of which is in the public
>> domain,
>> > from the Concurrency Interest Site [1] can be used as-is, as least
>> to the
>> > greatest extent possible. Are there any major dissents to this?
>>
>> This is my understanding of what we already agreed to, and I'm getting a
>> note from Doug about the code provenance.
>>
>
> I was not able to see any open documentation on sun.misc.Unsafe on the
> web. I did notice emails that describe using sun.misc.Unsafe to
> read/write specific memory addresses. I suspect that both
> sun.misc.Unsafe and Jikes vmmagic do essentially the same thing. That
> is, read/write and also compare/swap specific memory addresses from
> Java code.
>
> MMTk definitely relies on efficient JIT inlining of Jikes vmmagic. It
> also looks like java.util.concurrent needs efficient JIT inlining of
> sun.misc.Unsafe. If indeed both vmmagic and Unsafe do the same thing,
> it probably does not make sense to rewrite Concurrency or MMTk. In
> other words, we might be stuck with supporting both APIs in the short
> term.
>
> In any case, can the sun.misc.Unsafe API be described on this mailing
> list? It would help us all figure out what existing pieces can be
> reused to support high-performance java.util.concurrent.
If you are asking "are we allowed?" I see no reason why not - we're just
trying to figure out what it does based on the j.u.c code...
I don't think anyone here has specific knowledge of it, and if they do,
given it's not under an open source license, they shouldn't be telling us :)
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][concurrent] Integrating into builds and snapshot
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Andrey Chernyshev wrote:
>
> I agree that j.u.c. will need efficient inlining for the Unsafe.
> However, if the Harmony impl of Unsafe does nothing but simple call
> forwarding to the appropriate methods of vmmagic, then we probably
> won't get that big overhead.
> In other words, we can try keeping Unsafe interface as a bridge
> between j.u.c. and various VM's at the price of one extra method call
> to it's "real" implementation (which could be vmmagic in our case). It
> would be nice, however, if we can agree with the concurrency group to
> hide Unsafe under some other interface which would have a more neutral
> package name (e.g. not sun.misc).
>
Agreed. I think though that we should demonstrate why we want the
package change by successfully integrating into Harmony.
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][concurrent] Integrating into builds and snapshot
Posted by Andrey Chernyshev <a....@gmail.com>.
On 8/21/06, Weldon Washburn <we...@gmail.com> wrote:
> On 8/21/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >
> >
> > Nathan Beyer wrote:
> > > Now that we're getting some good submissions to make the
> > > java.util.concurrent code to work with DRLVM, I'd like make a proposal for
> > > getting the code in the Class Library and a part of our regular builds,
> > > tests and snapshots.
> > >
> > >
> > >
> > >>From a technical/code integration standpoint, the go ahead assumption is
> > > that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
> > > class, such that the concurrent code, most of which is in the public domain,
> > > from the Concurrency Interest Site [1] can be used as-is, as least to the
> > > greatest extent possible. Are there any major dissents to this?
> >
> > This is my understanding of what we already agreed to, and I'm getting a
> > note from Doug about the code provenance.
> >
>
> I was not able to see any open documentation on sun.misc.Unsafe on the
> web. I did notice emails that describe using sun.misc.Unsafe to
> read/write specific memory addresses. I suspect that both
> sun.misc.Unsafe and Jikes vmmagic do essentially the same thing. That
> is, read/write and also compare/swap specific memory addresses from
> Java code.
>
> MMTk definitely relies on efficient JIT inlining of Jikes vmmagic. It
> also looks like java.util.concurrent needs efficient JIT inlining of
> sun.misc.Unsafe. If indeed both vmmagic and Unsafe do the same thing,
> it probably does not make sense to rewrite Concurrency or MMTk. In
> other words, we might be stuck with supporting both APIs in the short
> term.
I agree that j.u.c. will need efficient inlining for the Unsafe.
However, if the Harmony impl of Unsafe does nothing but simple call
forwarding to the appropriate methods of vmmagic, then we probably
won't get that big overhead.
In other words, we can try keeping Unsafe interface as a bridge
between j.u.c. and various VM's at the price of one extra method call
to it's "real" implementation (which could be vmmagic in our case). It
would be nice, however, if we can agree with the concurrency group to
hide Unsafe under some other interface which would have a more neutral
package name (e.g. not sun.misc).
Thanks,
Andrey.
>
> In any case, can the sun.misc.Unsafe API be described on this mailing
> list? It would help us all figure out what existing pieces can be
> reused to support high-performance java.util.concurrent.
>
> Thanks
>
> ---------------------------------------------------------------------
> 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
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
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][concurrent] Integrating into builds and snapshot
Posted by Nathan Beyer <nb...@kc.rr.com>.
The sun.misc.Unsafe service stub is available at
http://svn.apache.org/repos/asf/incubator/harmony/standard/sandbox/juc-propo
sal/concurrent/src/main/java/sun/misc/Unsafe.java.
This is my best guess estimate of the interface based on the j.u.c code.
There is a partial implementation of this class in DRLVM trunk.
-Nathan
> -----Original Message-----
> From: Weldon Washburn [mailto:weldonwjw@gmail.com]
> Sent: Monday, August 21, 2006 1:07 PM
> To: harmony-dev@incubator.apache.org; geir@pobox.com
> Subject: Re: [classlib][concurrent] Integrating into builds and snapshot
>
> On 8/21/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >
> >
> > Nathan Beyer wrote:
> > > Now that we're getting some good submissions to make the
> > > java.util.concurrent code to work with DRLVM, I'd like make a proposal
> for
> > > getting the code in the Class Library and a part of our regular
> builds,
> > > tests and snapshots.
> > >
> > >
> > >
> > >>From a technical/code integration standpoint, the go ahead assumption
> is
> > > that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
> > > class, such that the concurrent code, most of which is in the public
> domain,
> > > from the Concurrency Interest Site [1] can be used as-is, as least to
> the
> > > greatest extent possible. Are there any major dissents to this?
> >
> > This is my understanding of what we already agreed to, and I'm getting a
> > note from Doug about the code provenance.
> >
>
> I was not able to see any open documentation on sun.misc.Unsafe on the
> web. I did notice emails that describe using sun.misc.Unsafe to
> read/write specific memory addresses. I suspect that both
> sun.misc.Unsafe and Jikes vmmagic do essentially the same thing. That
> is, read/write and also compare/swap specific memory addresses from
> Java code.
>
> MMTk definitely relies on efficient JIT inlining of Jikes vmmagic. It
> also looks like java.util.concurrent needs efficient JIT inlining of
> sun.misc.Unsafe. If indeed both vmmagic and Unsafe do the same thing,
> it probably does not make sense to rewrite Concurrency or MMTk. In
> other words, we might be stuck with supporting both APIs in the short
> term.
>
> In any case, can the sun.misc.Unsafe API be described on this mailing
> list? It would help us all figure out what existing pieces can be
> reused to support high-performance java.util.concurrent.
>
> Thanks
>
> ---------------------------------------------------------------------
> 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][concurrent] Integrating into builds and snapshot
Posted by Weldon Washburn <we...@gmail.com>.
On 8/21/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Nathan Beyer wrote:
> > Now that we're getting some good submissions to make the
> > java.util.concurrent code to work with DRLVM, I'd like make a proposal for
> > getting the code in the Class Library and a part of our regular builds,
> > tests and snapshots.
> >
> >
> >
> >>From a technical/code integration standpoint, the go ahead assumption is
> > that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
> > class, such that the concurrent code, most of which is in the public domain,
> > from the Concurrency Interest Site [1] can be used as-is, as least to the
> > greatest extent possible. Are there any major dissents to this?
>
> This is my understanding of what we already agreed to, and I'm getting a
> note from Doug about the code provenance.
>
I was not able to see any open documentation on sun.misc.Unsafe on the
web. I did notice emails that describe using sun.misc.Unsafe to
read/write specific memory addresses. I suspect that both
sun.misc.Unsafe and Jikes vmmagic do essentially the same thing. That
is, read/write and also compare/swap specific memory addresses from
Java code.
MMTk definitely relies on efficient JIT inlining of Jikes vmmagic. It
also looks like java.util.concurrent needs efficient JIT inlining of
sun.misc.Unsafe. If indeed both vmmagic and Unsafe do the same thing,
it probably does not make sense to rewrite Concurrency or MMTk. In
other words, we might be stuck with supporting both APIs in the short
term.
In any case, can the sun.misc.Unsafe API be described on this mailing
list? It would help us all figure out what existing pieces can be
reused to support high-performance java.util.concurrent.
Thanks
---------------------------------------------------------------------
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][concurrent] Integrating into builds and snapshot
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Didn't we agree to move it out of there?
geir
Nathan Beyer wrote:
> For now, I'm just going to put everything into
> 'enhanced/classlib/trunk/modules/concurrent' for the sake of simplicity. We
> can refactor later.
>
> -Nathan
>
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geir@pobox.com]
>> Sent: Monday, August 21, 2006 9:19 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib][concurrent] Integrating into builds and snapshot
>>
>> Nathan Beyer wrote:
>>> I think we're on the same page for all of this except for the placement
>> of
>>> the public domain code. I didn't state it explicitly, but my assumption
>> was
>>> that all of the code would go under the
>>> 'enhanced/classlib/trunk/modules/concurrent'. I probably should have
>> stated
>>> this, but I so rarely work outside of 'enhanced' that it slipped my
>> mind. I
>>> don't really care, but I'm not sure how we'd work the build.
>> Right - we'll figure that out. I hope to get it into enhanced as well.
>>
>>> Are you thinking that we can svn:external the code from 'standard' to
>>> 'enhanced', such that most of it just overlays a normal module code
>> layout?
>>
>> Nope :) I wasn't thinking anything. it's a ugly mess that makes my
>> head hurt.
>>
>>> The other options are having the build traverse up from classlib to
>> standard
>>> or have two JARs one with the public domain code and one with Harmony
>> code
>>> (COWAL). The public domain JAR could be built once and checked into the
>>> "depends" under classlib.
>> That would be odd, code from std checked in. Maybe we just tell devs to
>> do it and drop the jar in there...
>>
>> geir
>>
>>> -Nathan
>>>
>>>> -----Original Message-----
>>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>>> Sent: Monday, August 21, 2006 9:21 AM
>>>> To: harmony-dev@incubator.apache.org
>>>> Subject: Re: [classlib][concurrent] Integrating into builds and
>> snapshot
>>>>
>>>>
>>>> Nathan Beyer wrote:
>>>>> Now that we're getting some good submissions to make the
>>>>> java.util.concurrent code to work with DRLVM, I'd like make a proposal
>>>> for
>>>>> getting the code in the Class Library and a part of our regular
>> builds,
>>>>> tests and snapshots.
>>>>>
>>>>>
>>>>>
>>>>> >From a technical/code integration standpoint, the go ahead assumption
>> is
>>>>> that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
>>>>> class, such that the concurrent code, most of which is in the public
>>>> domain,
>>>>> from the Concurrency Interest Site [1] can be used as-is, as least to
>>>> the
>>>>> greatest extent possible. Are there any major dissents to this?
>>>> This is my understanding of what we already agreed to, and I'm getting
>> a
>>>> note from Doug about the code provenance.
>>>>
>>>>
>>>>> Now, the issue that's of most contention, at least from our past
>>>>> conversations, is the code management. First and foremost, we must
>>>> consider
>>>>> the realities of the situation.
>>>>>
>>>>>
>>>>>
>>>>> 1. The concurrency interest group, the JSR-166 expert group, Doug Lea
>>>> and
>>>>> others are NOT producing distributable builds, so we can not integrate
>>>> the
>>>>> code like we do other components, like Xerces, Xalan, MX4J, etc. I
>> don't
>>>>> want to speak for anyone here, so I'll qualify this by saying that I
>>>> haven't
>>>>> been told this explicitly, so this is just my inference from
>> discussions
>>>> and
>>>>> documentation. If this is not the case, then someone please speak up.
>>>> There
>>>>> is an experimental JAR on the site [1], but it's meant specifically to
>>>> run
>>>>> with the Sun RI and it contains code outside of the
>> java.util.concurrent
>>>>> package space. Additionally, the TCK tests from the site [1], which
>> we'd
>>>>> like to use are not packaged in any way.
>>>> Right - we should be able to slurp the tests in the same way as we do
>>>> the rest of it. In fact, we are less worried about the tests because
>> we
>>>> don't ship those.
>>>>
>>>> And lets just call them "tests", not "TCK test", because while they are
>>>> used in the TCK, something we get from Sun, they are just "tests" :)
>>>>
>>>>>
>>>>> 2. The code on the site [1] is only accessible through a ViewCVS Web
>>>>> interface. As such, it's not exactly easy to interact with in terms of
>>>>> created an automated checkout of the source to integrate into a build.
>>>> One
>>>>> of my thoughts was using the svn:externals feature to download source
>>>>> dynamically, but there are additional issues that make that especially
>>>>> difficult; these issues follow. Besides that, I'm not sure that
>>>>> svn:externals works with arbitrary URLs that aren't SVN repositories.
>>>> Who cares? We're not going to slurp the code from their site for
>>>> building...
>>>>
>>>>> 3. There is at least one source file that MUST NOT be used from the
>> site
>>>> [1]
>>>>> because it's not open to the public domain, the CopyOnWriteArrayList
>>>> [2].
>>>>> This will require at least one class to be developed as part of the
>>>> Harmony
>>>>> Class Library.
>>>> Yes.
>>>>
>>>>> 4. It's currently NOT feasible for Harmony to use the HEAD version of
>>>> the
>>>>> code, as it has been updated to utilize several Java 6 APIs, which
>>>> Harmony
>>>>> does not current provide, not even in stub form. Additionally, there
>> is
>>>> only
>>>>> one viable CVS tag (JSR166_PFD), but this tag is two years old and
>> some
>>>> of
>>>>> the code in it does not compile on current JLS3 compilers. This has
>> been
>>>>> discussed on the mailing list previously; please search the archives
>> if
>>>>> you're curious. As such, any checkouts out code that compiles would
>> have
>>>> to
>>>>> be done either using a date-based checkout (not really possible with
>>>>> ViewCVS) or a specific revision number for each file would have to be
>>>>> determined.
>>>>>
>>>>>
>>>>>
>>>>> Tactical Proposal (next 6 to 12 to ?? months) -
>>>>>
>>>>> My proposals for integration of the concurrency code is to retrieve
>> the
>>>>> latest possible codebase from the site [1], which is open to the
>> public
>>>>> domain and check it into our repository.
>>>>>
>>>>> * This code would include the TCK tests.
>>>> "tests"
>>>>
>>>>> * From a build standpoint, this code would be handled just like any
>>>> other
>>>>> module.
>>>> For now, we stuff it into the harmony/standard part of the repo.
>>>>
>>>>> * As a general rule, this code would NOT be subject to normal code
>>>> patches.
>>>>> The suggested process would be to submit patches and fixes to the
>>>>> concurrency interest group [1] and if/when the patches are accepted
>> and
>>>>> committed, the code can synchronized to get the updates. Upon occasion
>>>>> (every few months), code updates can be take from the site [1], if
>>>> deemed
>>>>> necessary and appropriate.
>>>> Right - I think people can and should submit the patches here to us
>>>> first, and we decide to reject or go to EG with them. Of course,
>> people
>>>> can independently talk to the EG, but they shouldn't try to represent
>>>> Harmony.
>>>>
>>>>
>>>>> * A minor issue is where the stub for the sun.misc.Unsafe class would
>> be
>>>>> placed (for compiles); my suggestion would be to just make it part of
>>>> the
>>>>> luni-kernel-stubs, but we can look at a concurrent-kernel-stubs JAR.
>>>> Sure.
>>>>
>>>>> Strategic Proposal -
>>>>>
>>>>> Once we have code working, at least in a snapshot state, we can
>> attempt
>>>> to
>>>>> do a number of this to ease the process and discrepancies.
>>>>>
>>>>> * Once a CopyOnWriteArrayList implementation is completed, we can
>> submit
>>>> it
>>>>> back to the concurrency group for inclusion.
>>>> Yep
>>>>
>>>>> * Design and propose an alternate "Unsafe" service interface that can
>> be
>>>>> submitted to the concurrency interest group for use by all VMs and
>> Class
>>>>> Libraries.
>>>> Well, ok. But is there anything wrong with it? It think a better
>> first
>>>> step is to simply ask them to standardize it into an non-sun namespace
>>>> .
>>>>> Unless there are any substantial objections, with practical and
>> workable
>>>>> alternative solutions, I plan on moving forward with this approach
>> next
>>>>> weekend.
>>>> Except for donating COWArrayList (which is a good idea), I thought this
>>>> was exactly how we were moving forward anyway? :)
>>>>
>>>> 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][concurrent] Integrating into builds and snapshot
Posted by Nathan Beyer <nb...@kc.rr.com>.
For now, I'm just going to put everything into
'enhanced/classlib/trunk/modules/concurrent' for the sake of simplicity. We
can refactor later.
-Nathan
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geir@pobox.com]
> Sent: Monday, August 21, 2006 9:19 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][concurrent] Integrating into builds and snapshot
>
> Nathan Beyer wrote:
> > I think we're on the same page for all of this except for the placement
> of
> > the public domain code. I didn't state it explicitly, but my assumption
> was
> > that all of the code would go under the
> > 'enhanced/classlib/trunk/modules/concurrent'. I probably should have
> stated
> > this, but I so rarely work outside of 'enhanced' that it slipped my
> mind. I
> > don't really care, but I'm not sure how we'd work the build.
>
> Right - we'll figure that out. I hope to get it into enhanced as well.
>
> >
> > Are you thinking that we can svn:external the code from 'standard' to
> > 'enhanced', such that most of it just overlays a normal module code
> layout?
>
> Nope :) I wasn't thinking anything. it's a ugly mess that makes my
> head hurt.
>
> >
> > The other options are having the build traverse up from classlib to
> standard
> > or have two JARs one with the public domain code and one with Harmony
> code
> > (COWAL). The public domain JAR could be built once and checked into the
> > "depends" under classlib.
>
> That would be odd, code from std checked in. Maybe we just tell devs to
> do it and drop the jar in there...
>
> geir
>
> >
> > -Nathan
> >
> >> -----Original Message-----
> >> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> >> Sent: Monday, August 21, 2006 9:21 AM
> >> To: harmony-dev@incubator.apache.org
> >> Subject: Re: [classlib][concurrent] Integrating into builds and
> snapshot
> >>
> >>
> >>
> >> Nathan Beyer wrote:
> >>> Now that we're getting some good submissions to make the
> >>> java.util.concurrent code to work with DRLVM, I'd like make a proposal
> >> for
> >>> getting the code in the Class Library and a part of our regular
> builds,
> >>> tests and snapshots.
> >>>
> >>>
> >>>
> >>> >From a technical/code integration standpoint, the go ahead assumption
> is
> >>> that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
> >>> class, such that the concurrent code, most of which is in the public
> >> domain,
> >>> from the Concurrency Interest Site [1] can be used as-is, as least to
> >> the
> >>> greatest extent possible. Are there any major dissents to this?
> >> This is my understanding of what we already agreed to, and I'm getting
> a
> >> note from Doug about the code provenance.
> >>
> >>
> >>> Now, the issue that's of most contention, at least from our past
> >>> conversations, is the code management. First and foremost, we must
> >> consider
> >>> the realities of the situation.
> >>>
> >>>
> >>>
> >>> 1. The concurrency interest group, the JSR-166 expert group, Doug Lea
> >> and
> >>> others are NOT producing distributable builds, so we can not integrate
> >> the
> >>> code like we do other components, like Xerces, Xalan, MX4J, etc. I
> don't
> >>> want to speak for anyone here, so I'll qualify this by saying that I
> >> haven't
> >>> been told this explicitly, so this is just my inference from
> discussions
> >> and
> >>> documentation. If this is not the case, then someone please speak up.
> >> There
> >>> is an experimental JAR on the site [1], but it's meant specifically to
> >> run
> >>> with the Sun RI and it contains code outside of the
> java.util.concurrent
> >>> package space. Additionally, the TCK tests from the site [1], which
> we'd
> >>> like to use are not packaged in any way.
> >> Right - we should be able to slurp the tests in the same way as we do
> >> the rest of it. In fact, we are less worried about the tests because
> we
> >> don't ship those.
> >>
> >> And lets just call them "tests", not "TCK test", because while they are
> >> used in the TCK, something we get from Sun, they are just "tests" :)
> >>
> >>>
> >>>
> >>> 2. The code on the site [1] is only accessible through a ViewCVS Web
> >>> interface. As such, it's not exactly easy to interact with in terms of
> >>> created an automated checkout of the source to integrate into a build.
> >> One
> >>> of my thoughts was using the svn:externals feature to download source
> >>> dynamically, but there are additional issues that make that especially
> >>> difficult; these issues follow. Besides that, I'm not sure that
> >>> svn:externals works with arbitrary URLs that aren't SVN repositories.
> >> Who cares? We're not going to slurp the code from their site for
> >> building...
> >>
> >>> 3. There is at least one source file that MUST NOT be used from the
> site
> >> [1]
> >>> because it's not open to the public domain, the CopyOnWriteArrayList
> >> [2].
> >>> This will require at least one class to be developed as part of the
> >> Harmony
> >>> Class Library.
> >> Yes.
> >>
> >>> 4. It's currently NOT feasible for Harmony to use the HEAD version of
> >> the
> >>> code, as it has been updated to utilize several Java 6 APIs, which
> >> Harmony
> >>> does not current provide, not even in stub form. Additionally, there
> is
> >> only
> >>> one viable CVS tag (JSR166_PFD), but this tag is two years old and
> some
> >> of
> >>> the code in it does not compile on current JLS3 compilers. This has
> been
> >>> discussed on the mailing list previously; please search the archives
> if
> >>> you're curious. As such, any checkouts out code that compiles would
> have
> >> to
> >>> be done either using a date-based checkout (not really possible with
> >>> ViewCVS) or a specific revision number for each file would have to be
> >>> determined.
> >>>
> >>>
> >>>
> >>> Tactical Proposal (next 6 to 12 to ?? months) -
> >>>
> >>> My proposals for integration of the concurrency code is to retrieve
> the
> >>> latest possible codebase from the site [1], which is open to the
> public
> >>> domain and check it into our repository.
> >>>
> >>> * This code would include the TCK tests.
> >> "tests"
> >>
> >>> * From a build standpoint, this code would be handled just like any
> >> other
> >>> module.
> >> For now, we stuff it into the harmony/standard part of the repo.
> >>
> >>> * As a general rule, this code would NOT be subject to normal code
> >> patches.
> >>> The suggested process would be to submit patches and fixes to the
> >>> concurrency interest group [1] and if/when the patches are accepted
> and
> >>> committed, the code can synchronized to get the updates. Upon occasion
> >>> (every few months), code updates can be take from the site [1], if
> >> deemed
> >>> necessary and appropriate.
> >> Right - I think people can and should submit the patches here to us
> >> first, and we decide to reject or go to EG with them. Of course,
> people
> >> can independently talk to the EG, but they shouldn't try to represent
> >> Harmony.
> >>
> >>
> >>> * A minor issue is where the stub for the sun.misc.Unsafe class would
> be
> >>> placed (for compiles); my suggestion would be to just make it part of
> >> the
> >>> luni-kernel-stubs, but we can look at a concurrent-kernel-stubs JAR.
> >> Sure.
> >>
> >>> Strategic Proposal -
> >>>
> >>> Once we have code working, at least in a snapshot state, we can
> attempt
> >> to
> >>> do a number of this to ease the process and discrepancies.
> >>>
> >>> * Once a CopyOnWriteArrayList implementation is completed, we can
> submit
> >> it
> >>> back to the concurrency group for inclusion.
> >> Yep
> >>
> >>> * Design and propose an alternate "Unsafe" service interface that can
> be
> >>> submitted to the concurrency interest group for use by all VMs and
> Class
> >>> Libraries.
> >> Well, ok. But is there anything wrong with it? It think a better
> first
> >> step is to simply ask them to standardize it into an non-sun namespace
> >> .
> >>>
> >>> Unless there are any substantial objections, with practical and
> workable
> >>> alternative solutions, I plan on moving forward with this approach
> next
> >>> weekend.
> >> Except for donating COWArrayList (which is a good idea), I thought this
> >> was exactly how we were moving forward anyway? :)
> >>
> >> 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][concurrent] Integrating into builds and snapshot
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Nathan Beyer wrote:
> I think we're on the same page for all of this except for the placement of
> the public domain code. I didn't state it explicitly, but my assumption was
> that all of the code would go under the
> 'enhanced/classlib/trunk/modules/concurrent'. I probably should have stated
> this, but I so rarely work outside of 'enhanced' that it slipped my mind. I
> don't really care, but I'm not sure how we'd work the build.
Right - we'll figure that out. I hope to get it into enhanced as well.
>
> Are you thinking that we can svn:external the code from 'standard' to
> 'enhanced', such that most of it just overlays a normal module code layout?
Nope :) I wasn't thinking anything. it's a ugly mess that makes my
head hurt.
>
> The other options are having the build traverse up from classlib to standard
> or have two JARs one with the public domain code and one with Harmony code
> (COWAL). The public domain JAR could be built once and checked into the
> "depends" under classlib.
That would be odd, code from std checked in. Maybe we just tell devs to
do it and drop the jar in there...
geir
>
> -Nathan
>
>> -----Original Message-----
>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>> Sent: Monday, August 21, 2006 9:21 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib][concurrent] Integrating into builds and snapshot
>>
>>
>>
>> Nathan Beyer wrote:
>>> Now that we're getting some good submissions to make the
>>> java.util.concurrent code to work with DRLVM, I'd like make a proposal
>> for
>>> getting the code in the Class Library and a part of our regular builds,
>>> tests and snapshots.
>>>
>>>
>>>
>>> >From a technical/code integration standpoint, the go ahead assumption is
>>> that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
>>> class, such that the concurrent code, most of which is in the public
>> domain,
>>> from the Concurrency Interest Site [1] can be used as-is, as least to
>> the
>>> greatest extent possible. Are there any major dissents to this?
>> This is my understanding of what we already agreed to, and I'm getting a
>> note from Doug about the code provenance.
>>
>>
>>> Now, the issue that's of most contention, at least from our past
>>> conversations, is the code management. First and foremost, we must
>> consider
>>> the realities of the situation.
>>>
>>>
>>>
>>> 1. The concurrency interest group, the JSR-166 expert group, Doug Lea
>> and
>>> others are NOT producing distributable builds, so we can not integrate
>> the
>>> code like we do other components, like Xerces, Xalan, MX4J, etc. I don't
>>> want to speak for anyone here, so I'll qualify this by saying that I
>> haven't
>>> been told this explicitly, so this is just my inference from discussions
>> and
>>> documentation. If this is not the case, then someone please speak up.
>> There
>>> is an experimental JAR on the site [1], but it's meant specifically to
>> run
>>> with the Sun RI and it contains code outside of the java.util.concurrent
>>> package space. Additionally, the TCK tests from the site [1], which we'd
>>> like to use are not packaged in any way.
>> Right - we should be able to slurp the tests in the same way as we do
>> the rest of it. In fact, we are less worried about the tests because we
>> don't ship those.
>>
>> And lets just call them "tests", not "TCK test", because while they are
>> used in the TCK, something we get from Sun, they are just "tests" :)
>>
>>>
>>>
>>> 2. The code on the site [1] is only accessible through a ViewCVS Web
>>> interface. As such, it's not exactly easy to interact with in terms of
>>> created an automated checkout of the source to integrate into a build.
>> One
>>> of my thoughts was using the svn:externals feature to download source
>>> dynamically, but there are additional issues that make that especially
>>> difficult; these issues follow. Besides that, I'm not sure that
>>> svn:externals works with arbitrary URLs that aren't SVN repositories.
>> Who cares? We're not going to slurp the code from their site for
>> building...
>>
>>> 3. There is at least one source file that MUST NOT be used from the site
>> [1]
>>> because it's not open to the public domain, the CopyOnWriteArrayList
>> [2].
>>> This will require at least one class to be developed as part of the
>> Harmony
>>> Class Library.
>> Yes.
>>
>>> 4. It's currently NOT feasible for Harmony to use the HEAD version of
>> the
>>> code, as it has been updated to utilize several Java 6 APIs, which
>> Harmony
>>> does not current provide, not even in stub form. Additionally, there is
>> only
>>> one viable CVS tag (JSR166_PFD), but this tag is two years old and some
>> of
>>> the code in it does not compile on current JLS3 compilers. This has been
>>> discussed on the mailing list previously; please search the archives if
>>> you're curious. As such, any checkouts out code that compiles would have
>> to
>>> be done either using a date-based checkout (not really possible with
>>> ViewCVS) or a specific revision number for each file would have to be
>>> determined.
>>>
>>>
>>>
>>> Tactical Proposal (next 6 to 12 to ?? months) -
>>>
>>> My proposals for integration of the concurrency code is to retrieve the
>>> latest possible codebase from the site [1], which is open to the public
>>> domain and check it into our repository.
>>>
>>> * This code would include the TCK tests.
>> "tests"
>>
>>> * From a build standpoint, this code would be handled just like any
>> other
>>> module.
>> For now, we stuff it into the harmony/standard part of the repo.
>>
>>> * As a general rule, this code would NOT be subject to normal code
>> patches.
>>> The suggested process would be to submit patches and fixes to the
>>> concurrency interest group [1] and if/when the patches are accepted and
>>> committed, the code can synchronized to get the updates. Upon occasion
>>> (every few months), code updates can be take from the site [1], if
>> deemed
>>> necessary and appropriate.
>> Right - I think people can and should submit the patches here to us
>> first, and we decide to reject or go to EG with them. Of course, people
>> can independently talk to the EG, but they shouldn't try to represent
>> Harmony.
>>
>>
>>> * A minor issue is where the stub for the sun.misc.Unsafe class would be
>>> placed (for compiles); my suggestion would be to just make it part of
>> the
>>> luni-kernel-stubs, but we can look at a concurrent-kernel-stubs JAR.
>> Sure.
>>
>>> Strategic Proposal -
>>>
>>> Once we have code working, at least in a snapshot state, we can attempt
>> to
>>> do a number of this to ease the process and discrepancies.
>>>
>>> * Once a CopyOnWriteArrayList implementation is completed, we can submit
>> it
>>> back to the concurrency group for inclusion.
>> Yep
>>
>>> * Design and propose an alternate "Unsafe" service interface that can be
>>> submitted to the concurrency interest group for use by all VMs and Class
>>> Libraries.
>> Well, ok. But is there anything wrong with it? It think a better first
>> step is to simply ask them to standardize it into an non-sun namespace
>> .
>>>
>>> Unless there are any substantial objections, with practical and workable
>>> alternative solutions, I plan on moving forward with this approach next
>>> weekend.
>> Except for donating COWArrayList (which is a good idea), I thought this
>> was exactly how we were moving forward anyway? :)
>>
>> 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][concurrent] Integrating into builds and snapshot
Posted by Nathan Beyer <nb...@kc.rr.com>.
I think we're on the same page for all of this except for the placement of
the public domain code. I didn't state it explicitly, but my assumption was
that all of the code would go under the
'enhanced/classlib/trunk/modules/concurrent'. I probably should have stated
this, but I so rarely work outside of 'enhanced' that it slipped my mind. I
don't really care, but I'm not sure how we'd work the build.
Are you thinking that we can svn:external the code from 'standard' to
'enhanced', such that most of it just overlays a normal module code layout?
The other options are having the build traverse up from classlib to standard
or have two JARs one with the public domain code and one with Harmony code
(COWAL). The public domain JAR could be built once and checked into the
"depends" under classlib.
-Nathan
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> Sent: Monday, August 21, 2006 9:21 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][concurrent] Integrating into builds and snapshot
>
>
>
> Nathan Beyer wrote:
> > Now that we're getting some good submissions to make the
> > java.util.concurrent code to work with DRLVM, I'd like make a proposal
> for
> > getting the code in the Class Library and a part of our regular builds,
> > tests and snapshots.
> >
> >
> >
> >>From a technical/code integration standpoint, the go ahead assumption is
> > that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
> > class, such that the concurrent code, most of which is in the public
> domain,
> > from the Concurrency Interest Site [1] can be used as-is, as least to
> the
> > greatest extent possible. Are there any major dissents to this?
>
> This is my understanding of what we already agreed to, and I'm getting a
> note from Doug about the code provenance.
>
>
> > Now, the issue that's of most contention, at least from our past
> > conversations, is the code management. First and foremost, we must
> consider
> > the realities of the situation.
> >
> >
> >
> > 1. The concurrency interest group, the JSR-166 expert group, Doug Lea
> and
> > others are NOT producing distributable builds, so we can not integrate
> the
> > code like we do other components, like Xerces, Xalan, MX4J, etc. I don't
> > want to speak for anyone here, so I'll qualify this by saying that I
> haven't
> > been told this explicitly, so this is just my inference from discussions
> and
> > documentation. If this is not the case, then someone please speak up.
> There
> > is an experimental JAR on the site [1], but it's meant specifically to
> run
> > with the Sun RI and it contains code outside of the java.util.concurrent
> > package space. Additionally, the TCK tests from the site [1], which we'd
> > like to use are not packaged in any way.
>
> Right - we should be able to slurp the tests in the same way as we do
> the rest of it. In fact, we are less worried about the tests because we
> don't ship those.
>
> And lets just call them "tests", not "TCK test", because while they are
> used in the TCK, something we get from Sun, they are just "tests" :)
>
> >
> >
> >
> > 2. The code on the site [1] is only accessible through a ViewCVS Web
> > interface. As such, it's not exactly easy to interact with in terms of
> > created an automated checkout of the source to integrate into a build.
> One
> > of my thoughts was using the svn:externals feature to download source
> > dynamically, but there are additional issues that make that especially
> > difficult; these issues follow. Besides that, I'm not sure that
> > svn:externals works with arbitrary URLs that aren't SVN repositories.
>
> Who cares? We're not going to slurp the code from their site for
> building...
>
> >
> > 3. There is at least one source file that MUST NOT be used from the site
> [1]
> > because it's not open to the public domain, the CopyOnWriteArrayList
> [2].
> > This will require at least one class to be developed as part of the
> Harmony
> > Class Library.
>
> Yes.
>
> >
> > 4. It's currently NOT feasible for Harmony to use the HEAD version of
> the
> > code, as it has been updated to utilize several Java 6 APIs, which
> Harmony
> > does not current provide, not even in stub form. Additionally, there is
> only
> > one viable CVS tag (JSR166_PFD), but this tag is two years old and some
> of
> > the code in it does not compile on current JLS3 compilers. This has been
> > discussed on the mailing list previously; please search the archives if
> > you're curious. As such, any checkouts out code that compiles would have
> to
> > be done either using a date-based checkout (not really possible with
> > ViewCVS) or a specific revision number for each file would have to be
> > determined.
> >
> >
> >
> > Tactical Proposal (next 6 to 12 to ?? months) -
> >
> > My proposals for integration of the concurrency code is to retrieve the
> > latest possible codebase from the site [1], which is open to the public
> > domain and check it into our repository.
> >
> > * This code would include the TCK tests.
>
> "tests"
>
> >
> > * From a build standpoint, this code would be handled just like any
> other
> > module.
>
> For now, we stuff it into the harmony/standard part of the repo.
>
> >
> > * As a general rule, this code would NOT be subject to normal code
> patches.
> > The suggested process would be to submit patches and fixes to the
> > concurrency interest group [1] and if/when the patches are accepted and
> > committed, the code can synchronized to get the updates. Upon occasion
> > (every few months), code updates can be take from the site [1], if
> deemed
> > necessary and appropriate.
>
> Right - I think people can and should submit the patches here to us
> first, and we decide to reject or go to EG with them. Of course, people
> can independently talk to the EG, but they shouldn't try to represent
> Harmony.
>
>
> >
> > * A minor issue is where the stub for the sun.misc.Unsafe class would be
> > placed (for compiles); my suggestion would be to just make it part of
> the
> > luni-kernel-stubs, but we can look at a concurrent-kernel-stubs JAR.
>
> Sure.
>
> >
> > Strategic Proposal -
> >
> > Once we have code working, at least in a snapshot state, we can attempt
> to
> > do a number of this to ease the process and discrepancies.
> >
> > * Once a CopyOnWriteArrayList implementation is completed, we can submit
> it
> > back to the concurrency group for inclusion.
>
> Yep
>
> >
> > * Design and propose an alternate "Unsafe" service interface that can be
> > submitted to the concurrency interest group for use by all VMs and Class
> > Libraries.
>
> Well, ok. But is there anything wrong with it? It think a better first
> step is to simply ask them to standardize it into an non-sun namespace
> .
> >
> >
> > Unless there are any substantial objections, with practical and workable
> > alternative solutions, I plan on moving forward with this approach next
> > weekend.
>
> Except for donating COWArrayList (which is a good idea), I thought this
> was exactly how we were moving forward anyway? :)
>
> 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
Re: [classlib][concurrent] Integrating into builds and snapshot
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Nathan Beyer wrote:
> Now that we're getting some good submissions to make the
> java.util.concurrent code to work with DRLVM, I'd like make a proposal for
> getting the code in the Class Library and a part of our regular builds,
> tests and snapshots.
>
>
>
>>>From a technical/code integration standpoint, the go ahead assumption is
> that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
> class, such that the concurrent code, most of which is in the public domain,
> from the Concurrency Interest Site [1] can be used as-is, as least to the
> greatest extent possible. Are there any major dissents to this?
This is my understanding of what we already agreed to, and I'm getting a
note from Doug about the code provenance.
> Now, the issue that's of most contention, at least from our past
> conversations, is the code management. First and foremost, we must consider
> the realities of the situation.
>
>
>
> 1. The concurrency interest group, the JSR-166 expert group, Doug Lea and
> others are NOT producing distributable builds, so we can not integrate the
> code like we do other components, like Xerces, Xalan, MX4J, etc. I don't
> want to speak for anyone here, so I'll qualify this by saying that I haven't
> been told this explicitly, so this is just my inference from discussions and
> documentation. If this is not the case, then someone please speak up. There
> is an experimental JAR on the site [1], but it's meant specifically to run
> with the Sun RI and it contains code outside of the java.util.concurrent
> package space. Additionally, the TCK tests from the site [1], which we'd
> like to use are not packaged in any way.
Right - we should be able to slurp the tests in the same way as we do
the rest of it. In fact, we are less worried about the tests because we
don't ship those.
And lets just call them "tests", not "TCK test", because while they are
used in the TCK, something we get from Sun, they are just "tests" :)
>
>
>
> 2. The code on the site [1] is only accessible through a ViewCVS Web
> interface. As such, it's not exactly easy to interact with in terms of
> created an automated checkout of the source to integrate into a build. One
> of my thoughts was using the svn:externals feature to download source
> dynamically, but there are additional issues that make that especially
> difficult; these issues follow. Besides that, I'm not sure that
> svn:externals works with arbitrary URLs that aren't SVN repositories.
Who cares? We're not going to slurp the code from their site for
building...
>
> 3. There is at least one source file that MUST NOT be used from the site [1]
> because it's not open to the public domain, the CopyOnWriteArrayList [2].
> This will require at least one class to be developed as part of the Harmony
> Class Library.
Yes.
>
> 4. It's currently NOT feasible for Harmony to use the HEAD version of the
> code, as it has been updated to utilize several Java 6 APIs, which Harmony
> does not current provide, not even in stub form. Additionally, there is only
> one viable CVS tag (JSR166_PFD), but this tag is two years old and some of
> the code in it does not compile on current JLS3 compilers. This has been
> discussed on the mailing list previously; please search the archives if
> you're curious. As such, any checkouts out code that compiles would have to
> be done either using a date-based checkout (not really possible with
> ViewCVS) or a specific revision number for each file would have to be
> determined.
>
>
>
> Tactical Proposal (next 6 to 12 to ?? months) -
>
> My proposals for integration of the concurrency code is to retrieve the
> latest possible codebase from the site [1], which is open to the public
> domain and check it into our repository.
>
> * This code would include the TCK tests.
"tests"
>
> * From a build standpoint, this code would be handled just like any other
> module.
For now, we stuff it into the harmony/standard part of the repo.
>
> * As a general rule, this code would NOT be subject to normal code patches.
> The suggested process would be to submit patches and fixes to the
> concurrency interest group [1] and if/when the patches are accepted and
> committed, the code can synchronized to get the updates. Upon occasion
> (every few months), code updates can be take from the site [1], if deemed
> necessary and appropriate.
Right - I think people can and should submit the patches here to us
first, and we decide to reject or go to EG with them. Of course, people
can independently talk to the EG, but they shouldn't try to represent
Harmony.
>
> * A minor issue is where the stub for the sun.misc.Unsafe class would be
> placed (for compiles); my suggestion would be to just make it part of the
> luni-kernel-stubs, but we can look at a concurrent-kernel-stubs JAR.
Sure.
>
> Strategic Proposal -
>
> Once we have code working, at least in a snapshot state, we can attempt to
> do a number of this to ease the process and discrepancies.
>
> * Once a CopyOnWriteArrayList implementation is completed, we can submit it
> back to the concurrency group for inclusion.
Yep
>
> * Design and propose an alternate "Unsafe" service interface that can be
> submitted to the concurrency interest group for use by all VMs and Class
> Libraries.
Well, ok. But is there anything wrong with it? It think a better first
step is to simply ask them to standardize it into an non-sun namespace
.
>
>
> Unless there are any substantial objections, with practical and workable
> alternative solutions, I plan on moving forward with this approach next
> weekend.
Except for donating COWArrayList (which is a good idea), I thought this
was exactly how we were moving forward anyway? :)
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][concurrent] Integrating into builds and snapshot
Posted by Mikhail Loenko <ml...@gmail.com>.
I'd like to bring this back.
API signatures of that we use in Harmony (tag=JSR166_PFD), differ
from what is in the RI, this causes JAPI diffs [1,2]
We may consider several options to fix that:
1. replace affected files by newer versions. That would mean that we
will use minimal version sufficient to fix JAPI diffs
2. replace the whole j.u.c. with newer version:
a) get some snapshot after all the Java5 changes are in and before Java6-related
changes started to appear
OR
b) get snapshot at just before the first dependency on Java6 API appeared
3. take up-to-date version of all the files and manually replace those files
that use Java6 API with their older versions
Each of the options implies a risk that we will take some broken state,
but what we have not in SVN has the same risk too
Other considerations/options?
Thanks,
Mikhail
[1] http://www.kaffe.org/~stuart/japi/htmlout/h-harmony-jdk15.html#pkg_java_util_concurrent
[2] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_util_concurrent
2006/8/21, Nathan Beyer <nb...@kc.rr.com>:
> Now that we're getting some good submissions to make the
> java.util.concurrent code to work with DRLVM, I'd like make a proposal for
> getting the code in the Class Library and a part of our regular builds,
> tests and snapshots.
>
>
>
> From a technical/code integration standpoint, the go ahead assumption is
> that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
> class, such that the concurrent code, most of which is in the public domain,
> from the Concurrency Interest Site [1] can be used as-is, as least to the
> greatest extent possible. Are there any major dissents to this?
>
>
>
> Now, the issue that's of most contention, at least from our past
> conversations, is the code management. First and foremost, we must consider
> the realities of the situation.
>
>
>
> 1. The concurrency interest group, the JSR-166 expert group, Doug Lea and
> others are NOT producing distributable builds, so we can not integrate the
> code like we do other components, like Xerces, Xalan, MX4J, etc. I don't
> want to speak for anyone here, so I'll qualify this by saying that I haven't
> been told this explicitly, so this is just my inference from discussions and
> documentation. If this is not the case, then someone please speak up. There
> is an experimental JAR on the site [1], but it's meant specifically to run
> with the Sun RI and it contains code outside of the java.util.concurrent
> package space. Additionally, the TCK tests from the site [1], which we'd
> like to use are not packaged in any way.
>
>
>
> 2. The code on the site [1] is only accessible through a ViewCVS Web
> interface. As such, it's not exactly easy to interact with in terms of
> created an automated checkout of the source to integrate into a build. One
> of my thoughts was using the svn:externals feature to download source
> dynamically, but there are additional issues that make that especially
> difficult; these issues follow. Besides that, I'm not sure that
> svn:externals works with arbitrary URLs that aren't SVN repositories.
>
>
>
> 3. There is at least one source file that MUST NOT be used from the site [1]
> because it's not open to the public domain, the CopyOnWriteArrayList [2].
> This will require at least one class to be developed as part of the Harmony
> Class Library.
>
>
>
> 4. It's currently NOT feasible for Harmony to use the HEAD version of the
> code, as it has been updated to utilize several Java 6 APIs, which Harmony
> does not current provide, not even in stub form. Additionally, there is only
> one viable CVS tag (JSR166_PFD), but this tag is two years old and some of
> the code in it does not compile on current JLS3 compilers. This has been
> discussed on the mailing list previously; please search the archives if
> you're curious. As such, any checkouts out code that compiles would have to
> be done either using a date-based checkout (not really possible with
> ViewCVS) or a specific revision number for each file would have to be
> determined.
>
>
>
> Tactical Proposal (next 6 to 12 to ?? months) -
>
> My proposals for integration of the concurrency code is to retrieve the
> latest possible codebase from the site [1], which is open to the public
> domain and check it into our repository.
>
> * This code would include the TCK tests.
>
> * From a build standpoint, this code would be handled just like any other
> module.
>
> * As a general rule, this code would NOT be subject to normal code patches.
> The suggested process would be to submit patches and fixes to the
> concurrency interest group [1] and if/when the patches are accepted and
> committed, the code can synchronized to get the updates. Upon occasion
> (every few months), code updates can be take from the site [1], if deemed
> necessary and appropriate.
>
> * A minor issue is where the stub for the sun.misc.Unsafe class would be
> placed (for compiles); my suggestion would be to just make it part of the
> luni-kernel-stubs, but we can look at a concurrent-kernel-stubs JAR.
>
>
>
> Strategic Proposal -
>
> Once we have code working, at least in a snapshot state, we can attempt to
> do a number of this to ease the process and discrepancies.
>
> * Once a CopyOnWriteArrayList implementation is completed, we can submit it
> back to the concurrency group for inclusion.
>
> * Design and propose an alternate "Unsafe" service interface that can be
> submitted to the concurrency interest group for use by all VMs and Class
> Libraries.
>
>
>
> Unless there are any substantial objections, with practical and workable
> alternative solutions, I plan on moving forward with this approach next
> weekend.
>
>
>
> Thanks,
>
> -Nathan Beyer
>
>
>
> [1] http://gee.cs.oswego.edu/dl/concurrency-interest/
>
> [2]
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu
> rrent/CopyOnWriteArrayList.java?rev=HEAD&content-type=text/vnd.viewcvs-marku
> p
>
>