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. 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. 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
