On 06/25/2013 09:24 PM, Mandy Chung wrote:
I'm asking here, to hear any arguments against making such API
supported and public. Are there any security or other issues? If
there aren't, what steps should be taken to introduce such API in the
JDK8 timeframe? I'm thinking of a no-arg method, say
j.l.Class.getCaller() and moving @CallerSensitive to a supported
package + enabling it to mark methods in any class (not just system
and ext classes)...
Besides providing a method returning the caller's class, I'd like to
consider what other options we have and different use cases could be
satisfied by different API. For #2, the problem is that the API to
find a resource, it requires to use the ClassLoader with the right
visibility (the caller's class loader). This is similiar to 8013839 :
Enhance Logger API for handling of resource bundles [1]. For example,
a static method Class.getResource to use the caller's class loader to
find the given resource might be an alternative?
Might be enough sometimes, but usually the ClassLoader is not enough,
since the location of resources (resource path) might be determined by
caller's class name or package (relative to caller's class, for
example). So perhaps, if j.l.Class object is to security sensitive, a
tuple (caller ClassLoader, caller class name) might be enough for #2 usages.
Regards, Peter
