Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of nbeyer@kc.rr.com designates
 24.94.166.115 as permitted sender)
From: "Nathan Beyer" <nbeyer@kc.rr.com>
To: <harmony-dev@incubator.apache.org>
Subject: [classlib][concurrent] java.util.concurrent module proposal
Date: Tue, 11 Jul 2006 23:48:47 -0500
Message-ID: <005401c6a56e$79234ce0$0c01a8c0@LITTLEGUY>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0055_01C6A544.904D44E0"
Thread-index: AcalbnYlGSe4tJ/3T8e8XJPA2SHQgw==

------=_NextPart_000_0055_01C6A544.904D44E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I've checked in my proposal for the java.util.concurrent module at
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/s
andbox/juc-proposal.

 
The README gives a high level overview of the content. I've generated some
documentation and published it here for easier browsing:
http://people.apache.org/~ndbeyer/concurrent/project-reports.html.

 
Design -

Most of the code is straight from Doug Lea and the JSR group. The only piece
I've added are the service interfaces that the VM must implement and I've
uplifted the original code, where necessary to utilize these VM service
interfaces.

 
org.apache.harmony.concurrent.AtomicSupport [1] - The service interface for
'java.util.concurrent.atomic' features such as CAS (compare and swap) and
volatile read/writes.

 
org.apache.harmony.concurrent.LocksSupport [2] - The service interface for
'java.util.concurrent.locks' support. This is similar to the
java.util.concurrent.locks.LockSupport contract.

 
These service interfaces would need to be implemented by a VM provider and
their implementations are registered using Service Provider configuration
files, as defined by the JAR specification [3]. The rationale for the design
of the support classes was to preserve as much of the original code as
possible, so as to facilitate future maintenance and isolate the external
variability with well-defined service contracts.

 
If you wan to see what source code changed, then extract the
'concurrent.tar.gz' and compare the 'concurrent' folder from there to the
'concurrent/src/main/java/java/util/concurrent' folder.

 
TODOs -

* Implement the service interfaces by a VM!!

* Setup the build scripts (trivial) - currently there's a 'pom.xml' that's
in the project, which can be used with Maven to run a build and generate
documentation (mvn package site). It was just quicker for me to do this
while I as hacking.

* Consider and possible implement base/default service providers for win32
and linux that VMs can use if they like.

* Determine the best place to integrate the TCK source, which is also
available at Doug Lea's site.

* There are a LOT of changes, fixes and enhancements to the code at Doug
Lea's site; consider what code we should additional take.

 
Let the discussions begin.

 
-Nathan

 
[1]
http://people.apache.org/~ndbeyer/concurrent/apidocs/org/apache/harmony/conc
urrent/AtomicSupport.html

[2]
http://people.apache.org/~ndbeyer/concurrent/apidocs/org/apache/harmony/conc
urrent/LocksSupport.html

[3]
http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider

 
------=_NextPart_000_0055_01C6A544.904D44E0--