JEP 176: Mechanical Checking of Caller-Sensitive Methods

[Jeroen Frijters]

John Rose wrote:
> Remi's idea (using invokedynamic) makes a good proof of concept, too.
> But because we use getCallerClass to observe a non-forgeable caller
> identity, the @CS mechanism has to be something that works "underneath"
> any visible bytecode pattern, at least in the caller.

Yes. In IKVM CallerID also serves the purpose of making it non-forgeable by the caller. The CallerID object that is passed must be a subclass of CallerID that is nested inside the class it represents, that way .NET code can't forge a CallerID either (for Java code it is a non-issue since it can't see the CallerID parameter anyway).

> Thinking out loud...  In JVM terms, a @CS method might also be
> implemented with two entry points like this:
> 
> class ImportantSystemAPI {
>   ...
>   /** Returns the name of the class of the calling method. */
>   @CallerSensitive
>   public static String currentClassName() {
>     return currentClassName(Reflection.getCallerClass());
>   }
>   private static String currentClassName(Class caller) {
>     return caller.getName();
>   }
> }

Maybe I'm misunderstanding, but I think my preference would be to hide the pattern from the Java developers, making the code less verbose and less fragile. HotSpot could simply add the extra parameter and turn Reflection.getCallerClass() into an intrinsic that loads the parameter.
 
> In fact, the derived values are more interesting than the class itself.

I haven't used it beyond Class and ClassLoader, but the CallerID indirection does make it easy to cache additional information (at the expense of having a field in every CallerID instance).

> And if we are ever to share linkage information across classes (a
> desirable thing, judging by experience in the ME world) then we need to
> be able to make resolved @CS sites be applicable across a group of
> classes (all sharing a common package or CL).

I don't think I understand this bit, but one thing my scheme lacks is a distinction between requiring the caller's Class and just its ClassLoader. It would be more efficient to be able to share a single CallerID between all classes in a ClassLoader.

Regards,
Jeroen