Replacement of sun.reflect.Reflection#getCallerClass

[Nick Williams]

Alright, I'm back! I'm sorry about my extended absence. I am over a month behind on my book (as mentioned in an earlier email) and I have been heads-down for a couple of weeks trying to get it finished. Still not finished yet, but I know people here are awaiting my feedback. I have several emails to respond to, so please bear with me. I'll be responding to several emails over the next few hours. I'll include in my last response an indication that I have finally caught up. All of my responses will be inline, starting with:

On Sep 3, 2013, at 7:33 PM, Mandy Chung wrote:

> On 9/3/13 1:17 AM, Jochen Theodorou wrote:
>>> Defining a SE supported @CallerSensitive and also getCallerClass API 
>>> poses the risk of "encouraging" developers to implement more @CS methods 
>>> while not fully understand its implication. 
>> 
>> Again I am curious... what is such an implication? That your method will behave different depending on from where it got called and, depending on if that is from an expected or unexpected source, you may get an expected or unexpected result here?
> 
> *and* this could lead to surprises and hard-to-diagnose issue to any framework/library or even another API provided in the same library calling a caller-sensitive method that can't tell if they get the true caller or not.
> 
> Caller-sensitivity is used in getting the right visibility (e.g. Resource.getBundle and Class.forName) and for security checks.

While I certainly agree that this is a big use-case for caller sensitivity, it's just the JVM's use case. Any library or application could potentially come up a different and perfectly legitimate use case. Log4j's three major use cases for caller sensitivity, for example, are not represented in this sentence.

> The platform's caller-sensitive methods involve both visibility and security.  For the former (visiability): the use cases of getCallerClass are mostly for gaining visibility to avoid having the client code to supply the appropriate ClassLoader or Class.  Such convenience has led to the existing stack walking code to search for a ClassLoader that it can find what the client code is asking for - it's not impossible that it might find the wrong ClassLoader but that happens to find a resource with the same name.  For the latter (security), caller sensitive methods have kept us having "so much fun" in the past CPU releases.
> 
> Groovy/log4j and other existing framework has already dealt with such problem and written some non-trivial code to solve this problem.  My point is more about the general app developers that need education and big warning in the documentation before they attempt learning this API to get the immediate caller.

Agreed. Big, huge warning. As big as you can make it, I'm okay with that. But don't restrict what developers can do.

> Couple months ago a few of us discussed some security issues we had fixed in the past and evaluated what we could do about them - one thing we want to do is to remove the caller sensitive-ness.  This is certainly a big big change and high compatibility risk - some future work.  Just to give you a sense how serious we are the security issue around caller-sensitive methods.
> 
> I'm happy to know that you will build into Groovy 3.x the ability to transport the caller class from the Groovy class.  I strongly believe this is the right thing to do and use the       ResourceBundle.getBundle and Class.forName with the ClassLoader parameter. No filtering and no magic caller class API as you said.
> 
> I have replied to Nick's patch with the focus on the ability to get Class instance from stack trace for diagnosability purpose.  I will soon bring up the discussion on the ability to get caller's Class / ClassLoader use case.
> 
> Until tomorrow.
> Mandy
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html