StackTraceElement question

Krystal Mok rednaxelafx at gmail.com
Mon Oct 8 14:35:09 UTC 2012


On Mon, Oct 8, 2012 at 10:25 PM, Christos Zoulas <christos at zoulas.com>wrote:

> On Oct 8, 11:07pm, david.holmes at oracle.com (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 StackTrace.java
> 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();
>             a.run();
>         } catch (Exception e) {
>             StackTraceElement[] ste = e.getStackTrace();
>             for (int i = 0; i < ste.length; i++)
>                 System.out.println(ste[i].getClassName());
>         }
>     }
> }
> $ javac Stacktrace.java
> $ java -cp . StackTrace
> I
> StackTrace
>
> Printing "I" here is expected. After all, that's the class where you're
getting run()'s implementation from.
It's not designed to tell people the actual type of the receiver of a
certain method invocation. And that's what you're really after, right?

- Kris



> | 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
> implications.
>
> christos
>
> christos
>



More information about the core-libs-dev mailing list