Hi Tom, On Thu, 2006-06-15 at 12:48 -0600, Tom Tromey wrote: > >>>>> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> 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.
Thanks! > 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. Nice trick! 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 > interested. 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. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
