StackTraceElement question
Christos Zoulas
christos at zoulas.com
Mon Oct 8 14:25:18 UTC 2012
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
| 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