[concurrency-interest] JSR166+backport: Licensing Issues

Doug Lea dl at cs.oswego.edu
Tue Sep 20 15:55:54 EDT 2005

Andrew John Hughes wrote:
> Thanks for your help.  With regard to including the code in GNU
> Classpath, we'd like to use java.util.concurrent code provided by you as
> an upstream provider.  Ideally, this would thus be based on some kind of
> stable release point, rather than a random CVS snapshot. 

There are CVS tags (like "JSR166_PFD") at release points.
But you are better off getting more recent versions, that
contain fixes. (There were three "serious" bugs in
initial Tiger release, but you might as well get others.)
And in fact, we are very near stable Mustang/JSE6 freeze,
so in a month or so, there will be very few changes for
a while, and then none at all for a longer while.

> Also, I note that the code, as-is, use some internal Sun classes
> (notably in the atomic classes).  Is there some documentation available
> which specifies what these external methods are expected to provide?

The only internal class used is "sun.misc.Unsafe". This (poorly
named) class should be familiar to all JVM implementors, since it
contains "intrinsics" underlying various JSRs that require
bytecode-like VM support in the era where people don't dare add byte
codes. Someday this class should undergo JCP standardization, but
different JVM providers seem to want to retain some flexibility about
it, so it probably still premature to standardize. I believe that
JikesRVM for example contains overlapping methods but in a differently 
named class. For simplicity, I believe that all the commercial JVMs
contain supersets of the Sun version. Implementation of this class
requires tight coupling with a JVM -- intrinsics are things
the look like methods, but act like bytecodes.


More information about the Concurrency-interest mailing list