harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject [classlib][concurrent] java.util.concurrent module proposal
Date Wed, 12 Jul 2006 04:48:47 GMT
I've checked in my proposal for the java.util.concurrent module at


The README gives a high level overview of the content. I've generated some
documentation and published it here for easier browsing:


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


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.



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









  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message