Thoughts on adding getElementClass() method to StackTraceElement?

Alan Bateman Alan.Bateman at
Sun Jun 16 16:42:36 UTC 2013

On 16/06/2013 15:29, Nick Williams wrote:
> On Jun 16, 2013, at 1:25 AM, Jeroen Frijters wrote:
>> :
>> SecurityManager.getClassContext() is not available to unpriviliged callers, so I don't think this a valid argument.
> Can you define what "is not available to unprivileged callers" means a little better? We use it in Log4j 2 when getCallerClass() isn't available, and it works just fine. I took a look at the Java code, and it's native, so there's no check there. (You can't instantiate a SecurityManager unless there's not currently a SecurityManager installed _OR_ the installed SecurityManager allows the creation (installation privilege isn't checked) of another SecurityManager. Is that what you're talking about?) I took a look at the native code, and I don't see anything there that would represent a privilege check that I recognized, but if I understood what you meant a little better I might see where I'm wrong.
The main thing is that the hack to extend SecurityManager (so that you 
can call the protected getClassContext method) is unlikely to work when 
there is security manager set. I can't tell what environments you have 
tested with but usually it means setting up the security policy so that 
the code base of your library is granted the permission. Even then you 
might still have an issue because there will likely be frames associated 
with other untrusted code on the stack. Maybe your code attempts to 
create the security manager does do with so privileges enabled, therwise 
everything that could potentially call you would also needed to be 
granted this permission.


More information about the core-libs-dev mailing list