[cp-patches] [generics] Patch: RFC: import jsr166
mark at klomp.org
Wed Jun 7 13:00:52 UTC 2006
On Thu, 2006-05-25 at 09:55 -0600, Tom Tromey wrote:
> This patch imports the jsr166 reference implementation. This is
> implements java.util.concurrency.
Nice. I'll write fsf legal to let them know how we are importing this
for the records. Please wait with the actual import till we get an ack
> It consists of several related changes:
> * A sanitize-jsr166 script which is run on a pristine download in
> order to remove copyrighted code and to change sun.* references to
> the appropriate gnu.* references.
> * A small addition to VMStackWalker to support the above. The new
> method is written in java so should not cause a big problem.
This seems nice except for that ignored null argument. Unfortunately I
don't have the code here (sitting in the train) to see how it is
actually used. Could you add an explicit check for ingnored == null so
we won't get a surprize later when someone does want to use it? Also is
VMStackWalker the right place? This doesn't really seem runtime specific
or really optimizable beyond what you have written.
> * Import of the RI code (after running the sanitize script).
> There are a couple minor hand-written changes as well, one to work
> around an apparent ecj bug.
> The upstream code goes in external/jsr166/
Where are these changes? They should be mentioned in the
external.jsr166/readme. Have you tried to submit them upstream? How do
we make sure they aren't lost on subsequent imports?
> * Removal of our versions of some classes provided with the RI:
> AbstractQueue and Queue.
How are these removed? This isn't done by the sanitize script.
> I have not tested the result at all. Until some VM supports the
> Unsafe API, I don't think there is a way to. I think getting this on
> the generics branch is probably the best way to enable VM implementors
> to do this.
There is also a testsuite for the new concurrent classes. We should
clearly mention how/where to find that and/or import it into Mauve.
> When this goes in I intend to check in the VMStackWalker to cvs trunk
> as well, to keep the VM APIs aligned.
Don't forget to mention this in the NEWS files.
> +++ external/jsr166/IMPORTING 1 Jan 1970 00:00:00 -0000
> @@ -0,0 +1,28 @@
> +The code in this directory comes from the JSR 166
> +reference implementation. The RI consists of a public
> +domain part and a part that is copyright Sun. We remove
> +the copyrighted code prior to import so as not to taint
> +our source repository. Also, we slightly modify the
> +resulting untainted code so that it does not refer to
> +APIs in the sun.* namespace.
> Index: external/jsr166/readme
> RCS file: external/jsr166/readme
> diff -N external/jsr166/readme
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ external/jsr166/readme 1 Jan 1970 00:00:00 -0000
> @@ -0,0 +1,45 @@
> +The software comprising JSR166 was written by Doug Lea with assistance
> +from members of JCP JSR-166 Expert roup and released to the public
> +domain, as explained at:
Missing g in [g]roup.
> , excepting portions
> +of the class java.util.concurrent.CopyOnWriteArrayList, which were
> +adapted from class java.util.ArrayList, written by Sun Microsystems,
> +Inc, which are used with kind permission, and subject to the
> +following: [...]
Since we explicitly remove these parts it is better to add the text of
the start of IMPORTING here instead of mentioning copyright statements
that aren't in any of the code we distribute.
Please do let upstream know how we are sharing and reusing the code as
soon as it is in.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://developer.classpath.org/pipermail/classpath-patches/attachments/20060607/f4dad59f/attachment.pgp
More information about the Classpath-patches