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 Mon, 17 Jul 2006 00:38:54 GMT

Nathan Beyer wrote:
>> -----Original Message-----
>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> <snip/>
>> 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.
> Sorry, I completely overlooked that.

Please be careful - I know it's difficult, but that's why we're so
careful about  bringing in foreign code.

>>> 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.
> I'm fine with doing this, but I thought there might be a copyright issue
> with using the 'sun.misc.Unsafe' class name. Additionally, the interface
> would have to be reverse engineered from the source that uses it. There
> isn't a stub of it in the ViewCVS repository that can be seen. Also, the
> .class file is NOT included in any of the JARs on the site. Are we cool with
> doing this?
> Note, just implementing 'sun.misc.Unsafe' may not be enough, as it seems
> that some pieces of the code make assumptions about internals of other
> classes. For example, LockSupport [1] retrieves the Field 'parkBlocker' from
> java.lang.Thread, which is not part of the public contract.

Well, we just modify Thread then?

> If we just want to stick to a pure compilation route, then I think we would
> likely have to get Doug, et al to adopt some VM agnostic APIs before we take
> this code.

I don't understand why.  If we implement sun.misc.Unsafe and make the
mod to Thread, what do we need to do to the code?


>>> * 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,
>> presumably.)
> I'd prefer to take HEAD myself and the code only uses JLS3, but there are
> dependencies on Java 6 APIs. For example, the ConcurrentHashMap uses the new
> AbstractMap.SimpleEntry class [1]. Also, there are a number of references to
> the new Arrays.copyXXX methods as well. Additionally, we talked about this a
> few times and I came away with that we should try to use the latest Java 5
> tag [2][3][4]. Just as a reminder: there hasn't been a new tag since the
> JSR166_PFD tag (over 2 years old), so it's either that or HEAD + Harmony
> building some Java 6 APIs. Note, I'm perfectly fine with doing that as we'll
> need to do it eventually.

either one - seems like the simple route for now is the 166 tag used in
Tiger, and then we circle back once this is in.  Goal is to get Java 5

Again, thanks for doing this.  Don't let this minor process debate over
provenance distract you from this mighty feat!


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