Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

John Rose john.r.rose at oracle.com
Wed Apr 3 21:56:27 UTC 2013


On Apr 3, 2013, at 12:52 PM, Jeroen Frijters <jeroen at sumatra.nl> wrote:

> Thanks for this. This is a really great change.
> 
> I reviewed the changes and my only comment is that there is a typo in java/lang/reflect/Field.java ("scurity").

Thanks!

> Somewhat unrelated (but relevant for my implementation of CallerSensitive), but would it be possible to mark java.lang.Runtime as final, or at least make the CallerSensitive methods final?
> 
> The interaction between CallerSensitive and method overriding is non trivial, so IMO it is best avoided.

That is very true.  We are working on separating those two patterns.

Making Runtime and/or Runtime.load* final is an API change, which is harder to do than an implementation change.

Given that Runtime.<init> is private, it seems to me that there is no way to execute an override of those load methods, even if one could (deviously) load a subclass into the JVM.  It would be valid behavior, I think, for the JVM to quietly refuse to override them, because there would be no way to observe the refusal.

Note that the technique of a private <init> method is the recommended way to prevent instantiation of subclasses, and is used throughout the JDK.  This should be sufficient to prevent undesired interactions with @CS and overrides.

What do you think?

— John


More information about the core-libs-dev mailing list