harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib][concurrent] Integrating into builds and snapshot
Date Tue, 22 Aug 2006 02:18:43 GMT
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...


> -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

View raw message