On 11/16/2015 08:16 PM, Mandy Chung wrote:
On Nov 15, 2015, at 10:59 AM, Peter Levart <peter.lev...@gmail.com> wrote:
OTOH in the described cases, a caller of walker.getCallerClass() is actually expecting to be called
by a Java method, right? So what would it be if such "caller-sensitive" method demanded
to be called by a Java method and throw IllegalArgumentException("Not called by Java
method") otherwise?
Have you thought of that possibility?
Are you thinking about a JNI method calling getCallerClass? Or refer
getCallerClass being the bottom of the stack?
I don’t see any issue for a JNI method calling getCallerClass and it’s doing:
* Class<?> caller = walker.walk(s ->
* s.map(StackFrame::getDeclaringClass)
* .skip(2)
* .findFirst());
Mandy
Hi Mandy,
No, I was not thinking of StackWalker::getCallerClass being called by
JNI. I was thinking of a "caller-sensitive" method calling
getCallerClass() and that "caller-sensitive" method being called by JNI
from a newly attached thread.
1st, I don't think anyone will attempt calling getCallerClass() from the
static main() method invoked by java launcher. That's silly and need not
be supported.
2nd, I don't think anyone will attempt calling getCallerClass() from
overridden Thread::run() method. That too need not be supported.
So what we are left with are other "caller-sensitive" methods calling
getCallerClass(). Like for example:
public class Strings {
public static ResourceBundle getBundle() {
Class<?> cc = stackWalker.getCallerClass();
return ResourceBundle.getBundle(cc.getName() + "$Strings",
Locale.getDefault(), cc.getClassLoader());
}
}
Such method obviously expects to be called by some Java method. So it
may as well demand it. By throwing exception if it is called by JNI from
newly attached thread.
"caller-sensitive" methods could be viewed as taking an implicit
parameter - their caller. If that parameter is not specified, they could
behave like when some other explicit parameter was not specified or
invalid - throw new IllegalArgumentException("Not called by Java
method") ...
So instead of "pretending" they were called by themselves, which might
not be right, simply refuse the invocation with exception. I don't think
this would hinder any such caller-sensitive method in it's utility. More
importantly, it would prevent such methods from being abused.
You said about possible use-cases for getCallerClass:
I have been thinking what the users would do when there is no caller.
The JDK use of getCallerClass are to:
1. find the caller's class loader for class loader hierarchy check
Abuse: calling such "caller-sensitive" method by JNI from newly-attached
thread would use the caller-sensitive method's declaring class
ClassLoader for hierarchy check - wrong!
2. find the caller’s class loader to load something on behalf of the
caller (visibility)
Abuse: ... would use the caller-sensitive method's declaring class
ClassLoader to load something - might work, might not
3. looking forward to work with modules, one would want to get the
caller’s module
- to load something on behalf of the caller's module
Abuse: ...would load something from caller-sensitive method's declaring
class module - wrong.
- to add read edge to the caller’s module before accessing its type
Abuse: ...would add a read edge to itself before accessing some type -
wrong.
In all those cases throwing exception would be the right thing to do.
What do you think?
Regards, Peter
