PTH, is it impossible to determine the name of running class from static context?

[Guennadiy VANIN]

This question is really a synonym, at least for me, of the problem of getting to this from static context
.
The answer states:
"There is no complete equivalent" and then switches to what I did not ask (and even myself formulated). The answer, yet, hints that static context is early bound and, therefore, implies, that it is impossible to receive run-time information.
But, somehow, it is not exactly run-time information, it is information of the name of the same class/file that contains static method, that I am asking, and it is +- constant and fact, rigidly fixed, even at before running. The relation between static method and containing class/file is rigidly fixed.
Should I understand that there is absolutely no way around to get to any details of running context from static environment, e.g. determine from static context the name of the class currently running?
[This message has been edited by G Vanin (edited October 29, 2001).]

[David O'Meara]

If you absolutely need a solution and don't care how ugly it is, throw and catch an exception then parse the stack trace for the Class name...

public static void staticMethod()
{
    try
    {
        throw new FakeException();
    }
    catch(Exception e)
    {
        //parse and get Class from e
    }
}

I believe the JDK1.4 exception stuff makes this easier, but if you get it working, drop some code for us all to share
Dave

[Guennadiy VANIN]

David,
(unfortunately) I work with JDK1.3. This is because a couple of months ago my chiefs tested JDK1.4 and decided that it is very buggy (in areas where we use Java). What is your opinion.
Can you give a reference to differences of JDK1.3 with JDK1.4?

[Jim Yingst]

Well, 1.4 has an API that allows you to access stack trace info through the StackTraceElement class. Prior to 1.4, the format of a stack trace is completely unspecified. You can look at a stack trace and see how it's organized, but there is no guarantee that other JDKs will give you the same format. If you're developing for a single JDK edition you needn't worry about this, but it's something to be aware of. You can then study the stack trace format and figure out how to parse out the class name.
Note that there is really no reason to bother throwing and catching an exception. It would be sufficient to simply create it with new and print it:
<pre>
public static String getStackTraceString()
{
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter(sw);
new Throwable().printStackTrace(pw);
pw.flush();
return sw.toString();
}
</pre>
You still get the fun part of figuring out how to isolate the class name.

[This message has been edited by Jim Yingst (edited October 29, 2001).]

[Peter den Haan]

Originally posted by David O'Meara:
If you absolutely need a solution and don't care how ugly it is, throw and catch an exception then parse the stack trace for the Class name...

Nope, you can't, it won't work. Try it. You'll get the name of the class in which the method is implemented, not the name of the (sub)class through which the method was invoked.
I can only reiterate my earlier answer: there is no equivalent. The code snippets I gave may not be what was asked for, but they are as close as you can get. Static calls are bound at compile time. It is impossible to receive run-time information about this because there is no such run-time information. If B extends A then B.staticMethod() compiles to the very same bytecode as A.staticMethod() (assuming staticMethod() is not overridden in B) - a single invokestatic operation on the method implementation class. Again, try it, create the classes then run the calls through javap -c.
I would not expect the JDK 1.4 stack trace to be any different. More easily accessible, but no different. The VM spec didn't change, or did it?
- Peter

[This message has been edited by Peter den Haan (edited October 29, 2001).]

[Jim Yingst]

> Nope, you can't, it won't work. Try it. You'll get the name of
> the class in which the method is implemented, not the name of
> the (sub)class through which the method was invoked.
I see both class names when I print out a stack trace:
<pre>
java.lang.Throwable
at test.TestLog.getStackTraceString(TestLog.java:16)
at test.Test.main(Test.java:9)
</pre>
Of course, there would be even more lines in most programs - but the class we're interested in should always be on the third line. Unless, as I suggested above, some JVM's print a different format for this information? Or don't have it all?
Using 1.4, the whole problem is substantially easier:
<pre>
public static String getClassName()
{
return new Throwable().getStackTrace()[1].getClassName();
}
</pre>

[Guennadiy VANIN]

Thank you all, really. Done.
I did not ask about determining run-time information. It is all to the contrary!
It was to determine the name of a class/file the static method is in. All is known, fixed, dealt by compiler, before run-time. Compiler is dealing/parsing with all it. It is early bound.
It is overridable/overriding/overriden methods where the context/invocation point is pretty uncertain, or DYNAMIC, determined at run time, and is not (and cannot be) solved at compile time (because someone may enter that name to the textbox of running application).
Static methods are bound at compile time. YOU MAY NOT OVERRIDE THEM. It is a compile-time error
[This message has been edited by G Vanin (edited October 29, 2001).]

[Peter den Haan]

Originally posted by Jim Yingst:
I see both class names when I print out a stack trace: [...]

Jim, we're not talking about the same thing. Maybe I'm misinterpreting the question. My point was that if you have two classes

class A {
   public static void x() { }
}
class B extends A {
}

then it is impossible to distinguish A.x() from B.x().
GV, you may override static methods. But the implementation class that is invoked depends on the static, compile-time context of the call. I.e., in

class A {
   public static void x() { }
}
class B extends A {
   public static void x() { }
}
...
A a = new B();
a.x();

It is A.x() being called, not B.x() as would have been the case with an instance method. One of the reasons why it isn't good style to call static methods using an object reference.
- Peter

[This message has been edited by Peter den Haan (edited October 30, 2001).]