JEP 176: Mechanical Checking of Caller-Sensitive Methods (original) (raw)
Jeroen Frijters jeroen at sumatra.nl
Sat Mar 2 11:27:54 UTC 2013
- Previous message: JEP 176: Mechanical Checking of Caller-Sensitive Methods
- Next message: JEP 176: Mechanical Checking of Caller-Sensitive Methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
Regards, Jeroen
- Previous message: JEP 176: Mechanical Checking of Caller-Sensitive Methods
- Next message: JEP 176: Mechanical Checking of Caller-Sensitive Methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]