StackTraceElement question

Christos Zoulas christos at
Mon Oct 8 14:25:18 UTC 2012

On Oct 8, 11:07pm, david.holmes at (David Holmes) wrote:
-- Subject: Re: StackTraceElement question

| > There is also the problem of having a class hierarchy like:
| >
| > class A extends class I
| > class B extends class I
| >
| > and then trying to figure out if it is A or B when you just have I from
| > that StackTraceElement.
| Can't say I have ever studied stacktraces in depth but I would expect to 
| see A or B not I as the name.

I was expecting the same, but this is not the case:

$ cat
class I {
    public void run()
        throws Exception
        throw new Exception();

class A
   extends I

public class StackTrace {
    public static void main(String[] args) {
        try {
            A a = new A();
        } catch (Exception e) {
            StackTraceElement[] ste = e.getStackTrace();
            for (int i = 0; i < ste.length; i++)
$ javac
$ java -cp . StackTrace

| The loader issue is real, you'd have to know where to locate the class. 
| But another reason to not store the Class reference is that it may 
| prevent the class from being unloaded. For every use-case there's a 
| counter-use-case.

Yes, the class loader issue is real. I am not sure about the Class
reference preventing the class to be unloaded; after all, the
StackTraceElements are typically transient (when the exception goes
out of context, they can be GC'ed); if not, then the reference can
be held until the StackTraceElement is not reachable. I don't think
that keeping the reference is such a big issue to even consider
making this Weak. I am really worried about the security implications.
As far as serialization goes, it could be made transient for
compatibility.  Anyway, I would be more than happy the StackTraceElement
contained the outermost enclosing class instead of the immediately
enclosing one.  Returning the Class<?> instance is still the most
versatile, but the one that needs most consideration because of its



More information about the core-libs-dev mailing list