harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib][concurrent] java.util.concurrent module proposal
Date Wed, 12 Jul 2006 23:27:35 GMT

Nathan Beyer wrote:
> 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.

First problem is that you included CopyOnWriteArrayList.java, which is
*not* a file we can take, as it's (c) Sun and under some unknown license.

I've deleted it from SVN.


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

I don't know what you mean by "uplift" - I'm guessing you mean how you
modified to not use sun.com.Unsafe?

I'd like to avoid modifying any of this code, and just using as is,
meaning for now we implement "sun.com.Unsafe" and whatever else, and
then lobby Doug to change to something neutral.

We might be able to get away with using the jar that is found on his
website (assuming we can get him to produce one w/o Sun code, which
isn't the case now), which would further drive the requirement that we
use the code unmodified.

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

Hm.  Maybe I don't understand (there's other feedback about using an SPI
earlier in the thread), but if we just implemented sun.misc.Unsafe,
aren't we done?


> TODOs -
> * Implement the service interfaces by a VM!!

Right now, this can only be DRLVM, since boot and jche don't use our
classlib yet.

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

yes, it would be trivial.

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

Just as part of the testsuite.

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

Doug suggested we take HEAD, which would include changes for Mustang,
but should be 100% compatible w/ Java 5.  (And it doesn't really matter
if we try and it's not true, as we aren't modifying any of his code,


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

View raw message