harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [classlib][concurrent] java.util.concurrent module proposal
Date Thu, 13 Jul 2006 00:18:20 GMT
> -----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


Mime
View raw message