harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [classlib][concurrent] Integrating into builds and snapshot
Date Thu, 24 Aug 2006 00:21:54 GMT
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


Mime
View raw message