JEP 176: Mechanical Checking of Caller-Sensitive Methods

Jeroen Frijters jeroen at
Sat Mar 2 11:27:54 UTC 2013

Remi Forax wrote:
> I've always found that getCallerClass() was done at the wrong side of
> the problem, i.e. asked inside the callee instead of being inserted at
> callsite.

Yes, I agree and in fact in the IKVM implementation a CallerID parameter is added to each method that has the HasCallerID annotation. The reason for the CallerID abstraction instead of simply passing a Class is performance. Constructing a Class is expensive on IKVM (and was even more expensive back when CallerID was introduced) and in many cases caller sensitive methods are only sometimes caller sensitive, so I want the class construction to be lazy. It's also possible to return the ClassLoader without actually constructing the class.

>From the .NET side an IKVM HasCallerID method looks something like this:

public class Class
  [EditorBrowsable(Never)] // hide from .NET IDEs
  public static Class forName(String name, CallerID callerID) { ... }

  public static Class forName(String name)
    return forName(name, CallerID.create(new StackFrame(1)));

The Java compiler calls the method with the explicit CallerID parameter and .NET code can simply call the other method.


More information about the core-libs-dev mailing list