Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <44F516F1.6060605@pobox.com>
Date: Wed, 30 Aug 2006 00:41:21 -0400
From: "Geir Magnusson Jr." <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][concurrent] Integrating into builds and snapshot
References: <006101c6c713$4de5a700$0201a8c0@LITTLEGUY>
In-Reply-To: <006101c6c713$4de5a700$0201a8c0@LITTLEGUY>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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