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:[EMAIL PROTECTED] > Sent: Monday, August 21, 2006 9:19 PM > To: [email protected] > 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:[EMAIL PROTECTED] > >> Sent: Monday, August 21, 2006 9:21 AM > >> To: [email protected] > >> 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: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
