"This bug is not available." On Jul 19, 2013, at 8:41 PM, Mandy Chung wrote:
> Peter, > > FYI. I have filed this RFE: > 8020968: Load resource files using the caller's class and class loader > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020968 > > Mandy > > On 6/25/2013 6:50 PM, Peter Levart wrote: >> Hi, >> >> I know that @CallerSensitive annotation was introduced to bring some order >> to JDK internal plumbings. It's scope was to support JDK internal usage, so >> it's use is limited to classes loaded by bootstrap or extension >> class-loaders. In JDK-internal code it is used mainly for implementing >> security-sensitive decisions. But since the >> sun.reflect.Reflection.getCallerClass(int) was public and unrestricted, it >> found it's way out into user code, where at least I know that it is used in >> two areas: >> >> 1 - to locate callers in the whole call-stack so that their location in >> class-path can be reported (Log4J is an example) >> 2 - to locate immediate caller so that some resources associated with it can >> be located and used (for example localization data in GUI applications) >> >> I don't know how wide-spread 1st usecase is, but the 2nd is common, since >> it's use enables APIs that need not explicitly pass-in the calling class in >> order to locate resources associated with it (and/or the class-loader of >> it). So it would be nice to have such supported API in JDK8 at least. >> >> 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)... >> >> Regards, Peter >> >
