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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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: [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]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
