[cp-patches] [generics] Patch: RFC: import jsr166
mark at klomp.org
Fri Jun 16 12:14:54 UTC 2006
On Thu, 2006-06-15 at 12:48 -0600, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <mark at klomp.org> writes:
> >> This patch imports the jsr166 reference implementation. This is
> >> implements java.util.concurrency.
> Mark> Nice. I'll write fsf legal to let them know how we are importing this
> Mark> for the records. Please wait with the actual import till we get an ack
> Mark> back.
> We got the ack recently, so I am going to start the import today.
> Mark> This seems nice except for that ignored null argument. Unfortunately I
> Mark> don't have the code here (sitting in the train) to see how it is
> Mark> actually used. Could you add an explicit check for ingnored == null so
> Mark> we won't get a surprize later when someone does want to use it?
> I will go one better and make the argument type in Unsafe an
> unaccessible inner class. That way if the argument, whatever it is,
> ever is not null, we'll see a compile-time error during the import.
Since we have a generic implementation of this method, and I don't see
an easy way to optimize it really for any runtime, would it make sense
to submit this implementation upstream so they can use something like an
package private helper method to provide this functionality.
java.util.concurrent.Reflection.verifyMemberAccess() would make the code
a little bit more self contained and more portable.
> Mark> Also is
> Mark> VMStackWalker the right place? This doesn't really seem runtime specific
> Mark> or really optimizable beyond what you have written.
> I am going to follow Jeroen's suggestion and not rename this. So it
> will be in sun.something instead.
Bleah. But I see the point since this is what the code expects. We just
have to be careful to point out that access to this new package should
also be restricted to bootstrap classes. Again it would be nice to
reformulate this construct in a way that is more generic. I don't have
the code in front of me (in the train again) but it seems like you can
do the same with SecurityManager.getClassContext(). If so we should
probably submit a change to use that to upstream if possible.
> I will do a real cvs import and then apply these as patches. I'll
> also document this process. I think they are probably bugs in the
> version of ecj I happen to have. I doubt upstream would be that
OK thanks. But if there are "bugs" or diffs left please let upstream
know. No point in keeping divergences if there is any chance to have
upstream adopt them.
-------------- 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/20060616/334342ee/attachment-0001.pgp
More information about the Classpath-patches