Hi Jeroen, On Tue, 2006-04-04 at 12:32 +0200, Jeroen Frijters wrote: > Mark Wielaard wrote: > > This looks OK and not too invasive. But I would like to see as little > > extensions added as possible so let me propose a hack that might > > prevent having to add the hook. Couldn't you override setAccessible() > > so that it throws an exception when you try to set it to true on an > > "internal" Constructor? That seems to have the same effect. > > Thanks for taking the time to respond. I don't think hacking > setAccessible would help, but maybe I'm misunderstanding your > suggestion. The idea is that code can benefit from the @Internal access > modifier, without having to be modified (e.g. that I can use it to make > the gnu.* classes private to the IKVM.GNU.Classpath.dll assembly).
And I might misunderstand the semantics of the @Internal access modifier. As I read your suggestion the VMClass.checkAccess() method is only invoked when the Constructor of the Class is not public. If that is the case and the calling class isn't in the same package the only way that newInstance() can succeed is if setAccessible(true) has been called on it already. And since you said you already have your own version of Constructor already I was hoping that you could just use that so no extra VMClass method was necessary. If I am totally wrong (maybe it is intended to also cover public classes and I just misunderstood the patch) then I think the VMClass.checkAccess() idea is pretty sane. The default implementation is clear and simple. And no other runtime hacker objected. It might actually be useful to others to experiment with "internal class optimizations" if it works out for you. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
