Mechanism to identify calling object/method?

java-programmer, Mechanism to identify calling object/method? Is there a mechanism within Java (J2SE 5) that would allow me to
identify which object and/or method is calling a target method?

For example, if I have method Class1.foo() that is being called from
Class2.bar(), is there a way for Class1.foo() to identify one or both
of the calling object and method?

-Nedron

java-programmer >> Mechanism to identify calling object/method? On 21 Mar 2006 15:08:47 -0800, "Nedron" <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

>Is there a mechanism within Java (J2SE 5) that would allow me to
>identify which object and/or method is calling a target method?
>
>For example, if I have method Class1.foo() that is being called from
>Class2.bar(), is there a way for Class1.foo() to identify one or both
>of the calling object and method?

see http://mindprod.com/jgloss/trace.html
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> Mechanism to identify calling object/method? Nedron <email***@***.com> wrote:
> Is there a mechanism within Java (J2SE 5) that would allow me to
> identify which object and/or method is calling a target method?
>
> For example, if I have method Class1.foo() that is being called from
> Class2.bar(), is there a way for Class1.foo() to identify one or both
> of the calling object and method?

Yes, at least half of it is possible. No, you shouldn't do it unless
you're looking for debugging information.

If you are trying to get information for debugging (for example, writing
to debug dump files and such, then the following is what you want:

new Throwable().printStackTrace();

There's also a version of printStackTrace that takes a PrintWriter.
There's also a getStackTrace() the returns an array of stack trace
elements containing information about the source file, line number,
method, class, etc. for each stack frame in the call stack. (It does
not contain the object).

If you're looking at doing this in live code, then you've got design
problems. Somewhere, you need to have actually told the code you're
calling which object it needs to interact with. Perhaps that should
have been during the call to the method, or perhaps elsewhere such as in
a constructor. In any case, it's not at all a good idea to try to
recover this information, having failed to retain it in the first place.
Even if the information available from Throwable.getStackTrace() is
sufficient for your needs, it leads to fragile code that will break at
some future time. For that reason, you really need to find a better
answer than making real use of the stack; though providing it to
developers for informational purposes is entirely normal.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

java-programmer >> Mechanism to identify calling object/method? For a normal program, it's better to redesign to avoid the need to do
this. If you have some special purpose that makes it necessary, there
are a couple of things you can do. The method is easier to get: you can
create a Throwable and then parse its stack trace. To get the object, I
think you need a runtime instrumentation system, like AspectJ.

java-programmer >> Mechanism to identify calling object/method? Thanks to all for the pointer to Throwable. That's exactly what I was
looking for. This is specifically to attempt debugging a very strange
multithreaded synchronization issue.

-David