harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][concurrent] java.util.concurrent module proposal
Date Thu, 13 Jul 2006 16:48:25 GMT
I think you may have inadvertently checked the code into the wrong
location in SVN.  Could you move it please?

Thanks
Tim

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.
> 
>>> 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.
> 
> 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.
> 
> [1]
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu
> rrent/locks/LockSupport.java?rev=1.21&only_with_tag=HEAD&content-type=text/v
> nd.viewcvs-markup
> 
> <snip/>
> 
>> 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?
>>
>> [SNIP]
>>
>>> TODOs -
> 
> <snip/> 
> 
>>> * 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.
> 
> [1]
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu
> rrent/ConcurrentHashMap.java?rev=1.91&content-type=text/vnd.viewcvs-markup
> [2]
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/%
> 3c4487711D.5060500@pobox.com%3e
> [3]
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/%
> 3C000401c68ccf$e2677df0$0f01a8c0@LITTLEGUY%3E
> [4]
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/%
> 3c000001c68dca$2ecd8950$0f01a8c0@LITTLEGUY%3e
> 
> 
>> geir
>>
>>
>> ---------------------------------------------------------------------
>> 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
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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


Mime
View raw message