Caller of current method
Scott Morrison
Is it possible to find which object called the currently executing method?
I haven't seen anything that could do this, but the fact that the Java
interpreter can provide tracebacks suggests that this may be possible.
Any suggestions?
Thanks, Scott Morrison
sc...@morrison.fl.net.au
Doug Bell
"Scott Morrison" <sc...@morrison.fl.net.au> wrote:
> Is it possible to find which object called the currently executing method?
> I haven't seen anything that could do this, but the fact that the Java
> interpreter can provide tracebacks suggests that this may be possible.
> Any suggestions?
Well, I've seen this question go by before and it looked interesting, so I
coded it up. Note that you can't tell which _object_ called you, but you
can tell from which class and method you were called.
The following:
------------------------- Test.java --------------------------
import java.io.ByteArrayOutputStream;
import java.io.PrintStream;
import java.util.StringTokenizer;
import java.util.NoSuchElementException;
public class Test extends java.applet.Applet {
public void init () {
whoCalledMe();
}
void whoCalledMe () {
Throwable t = new Throwable();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
t.printStackTrace(new PrintStream(baos));
StringTokenizer trace = new StringTokenizer(baos.toString());
String token;
try {
int count = 2;
do {
token = trace.nextToken();
if (token.equals("at"))
count--;
} while (count > 0);
token = trace.nextToken("(") + "()";
}
catch (NoSuchElementException e) {
token = "Not found";
}
System.out.println("Called from: " + token);
}
}
---------------------------------------------------------------
prints:
Called from: Test.init()
The parsing does depend on how Throwable.printStackTrace() formats the
display, and the language spec indicates that this may vary, but this
works with the standard
java.lang.Throwable
at Test.whoCalledMe(Test.java:14)
at Test.init(Test.java:10)
at sun.applet.AppletPanel.run(AppletPanel.java:259)
at java.lang.Thread.run(Thread.java:294)
format. The parsing can easily be changed to fit a different format.
Obviously, the more useful application is to have this iterate once more
in the while loop (init 'count' to 3) and have whoCalledMe() return
'token'. This way a routine which wants to know the name of the routine
which called them can call whoCalledMe() to get it returned as a String.
Also, I deliberately eliminated the name of the file and the source line
number, but if you want this just change:
token = trace.nextToken("(") + "()";
to:
token = trace.nextToken();
Doug Bell
db...@shvn.com
Gilles Iachelini
Hello Scott,
I could not imagine a reason for this operation. Could you give some hints
?
Greetings Gilles
Scott Morrison <sc...@morrison.fl.net.au> wrote in article
<01bba6c2$3cf25000$0100007f@localhost>...
> Is it possible to find which object called the currently executing
method?
> I haven't seen anything that could do this, but the fact that the Java
> interpreter can provide tracebacks suggests that this may be possible.
> Any suggestions?
>
> Thanks, Scott Morrison
> sc...@morrison.fl.net.au
>
Brian Lambert
When I see questions like this, it makes we wonder "why?". Just
curious, but why would this be useful information? What would you do
with it?
brian
lam...@shore.net
On 20 Sep 1996 07:20:59 GMT, "Scott Morrison"
Jonathan Locke
Brian Lambert wrote:
>
> When I see questions like this, it makes we wonder "why?". Just
> curious, but why would this be useful information? What would you do
> with it?
>
That part's easy. Two words. CODE ASSERTIONS.
J
/**
* Contract Java programmer at large (Jo...@SealevelSoftware.com)
* @param codeSpecifications Your project requirements.
* @return High quality, well documented Java code.
* @see SealevelSoftware at http://www.sealevelsoftware.com/sealevel/
*/
public JavaCode Jonathan_Locke(String codeSpecifications) { /*
Undocumented algorithm... ;-) */ }
Gordon McMillan
Doug Bell <db...@shvn.com> wrote in article
<dbell-20099...@news3.cts.com>...
> "Scott Morrison" <sc...@morrison.fl.net.au> wrote:
>
> > Is it possible to find which object called the currently executing
method?
> > I haven't seen anything that could do this, but the fact that the Java
> > interpreter can provide tracebacks suggests that this may be possible.
> > Any suggestions?
>
>
> Well, I've seen this question go by before and it looked interesting, so
I
> coded it up. Note that you can't tell which _object_ called you, but you
> can tell from which class and method you were called.
>
> The following:
<cool code snipped>
>
> The parsing does depend on how Throwable.printStackTrace() formats the
> display, and the language spec indicates that this may vary, but this
> works with the standard
<snip>
> Doug Bell
> db...@shvn.com
>
Interesting, but printStackTrace() doesn't work when using the Symantec JIT
compiler.
Don't know if that's a violation of the Java spec, but the availability of
printStackTrace() is not something I'd want to rely on.
I'd force the caller to provide his 'this'.
--
Gordon McMillan
McMillan Enterprises, Inc.
Doug Bell
"Gordon McMillan" <gm...@hypernet.com> wrote:
> Doug Bell <db...@shvn.com> wrote:
>
> > "Scott Morrison" <sc...@morrison.fl.net.au> wrote:
> >
> > > Is it possible to find which object called the currently executing
> method?
> > > I haven't seen anything that could do this, but the fact that the Java
> > > interpreter can provide tracebacks suggests that this may be possible.
> > > Any suggestions?
> >
> >
> > Well, I've seen this question go by before and it looked interesting, so I
> > coded it up. Note that you can't tell which _object_ called you, but you
> > can tell from which class and method you were called.
> >
> > The following:
> <cool code snipped>
> >
> > The parsing does depend on how Throwable.printStackTrace() formats the
> > display, and the language spec indicates that this may vary, but this
> > works with the standard
> <snip>
> > Doug Bell
> > db...@shvn.com
> >
> Interesting, but printStackTrace() doesn't work when using the Symantec JIT
> compiler.
> Don't know if that's a violation of the Java spec, but the availability of
> printStackTrace() is not something I'd want to rely on.
> I'd force the caller to provide his 'this'.
Well, I don't think I'd recommend relying on the code in any case. It was
just an interesting question, so I did it for the amusement value (I'm
easily amused.) It is interesting that it doesn't work on Symantec's
JIT. As far as I know, this is required functionality, so it would seem
to me to be a violation of the spec. From the language spec:
-----------
20.22.6:
public void printStackTrace()
This method prints a stack trace for this Throwable object on the error
output stream that is the value of the field System.err (§20.18.3). The
first line of output contains the result of the toString method (§20.22.4)
for this object. Remaining lines represent data previously recorded by the
method fillInStackTrace (§20.22.5). The format of this information depends
on the implementation, but the following example may be regarded as
typical:
java.lang.NullPointerException
at MyClass.mash(MyClass.java:9)
at MyClass.crunch(MyClass.java:6)
at MyClass.main(MyClass.java:3)
-----------
This seems to pretty clearly indicate that displaying at least the
toString() result of the exception is required functionality.
I can think of three applications of this trick:
1) For use with non-fatal assertions. However, using printStackTrace()
seems like it is adequate for this use.
2) To restrict access to a method, or features of a method based on where
called from. In this case, I'm not sure if the code I presented is secure
because it has no way to determine if the calling code is from the same
ClassLoader. Two classes from different ClassLoaders could have the same
fully-qualified class name and would still be different classes. However,
code from a different ClassLoader is very restricted in calling code in a
different ClassLoader, as only the API classes are in common, so I can't
think of how you could break this by exploiting this behavior.
3) To call a method in the calling class. This seems fairly useless, and
much better addressed by passing in 'this' or a Class object for the
class.
Using this approach for #2 seems pretty crude. One thing I have wished
for on occassion is the ability to have "friend" packages, so that
package-level access could be granted to specific friend packages. This
is the only time when I would have even considered something like this,
and still I would have found a better way.
Combined with the new Reflection API, there might be other novel uses...
Doug Bell
db...@shvn.com
Gordon McMillan
Reposting article removed by rogue canceller.
Doug Bell <db...@shvn.com> wrote in article
<dbell-20099...@news3.cts.com>...
> "Scott Morrison" <sc...@morrison.fl.net.au> wrote:
>
> > Is it possible to find which object called the currently executing
method?
> > I haven't seen anything that could do this, but the fact that the Java
> > interpreter can provide tracebacks suggests that this may be possible.
> > Any suggestions?
>
>
> Well, I've seen this question go by before and it looked interesting, so
I
> coded it up. Note that you can't tell which _object_ called you, but you
> can tell from which class and method you were called.
>
> The following:
<cool code snipped>
>
> The parsing does depend on how Throwable.printStackTrace() formats the
> display, and the language spec indicates that this may vary, but this
> works with the standard
<snip>
> Doug Bell
> db...@shvn.com
>
Interesting, but printStackTrace() doesn't work when using the Symantec JIT
compiler.
Don't know if that's a violation of the Java spec, but the availability of
printStackTrace() is not something I'd want to rely on.
I'd force the caller to provide his 'this'.
--
Doug Bell
Reposting article removed by rogue canceller.
"Gordon McMillan" <gm...@hypernet.com> wrote:
> Doug Bell <db...@shvn.com> wrote:
>
> > "Scott Morrison" <sc...@morrison.fl.net.au> wrote:
> >
> > > Is it possible to find which object called the currently executing
> method?
> > > I haven't seen anything that could do this, but the fact that the Java
> > > interpreter can provide tracebacks suggests that this may be possible.
> > > Any suggestions?
> >
> >
> > Well, I've seen this question go by before and it looked interesting, so I
> > coded it up. Note that you can't tell which _object_ called you, but you
> > can tell from which class and method you were called.
> >
> > The following:
> <cool code snipped>
> >
> > The parsing does depend on how Throwable.printStackTrace() formats the
> > display, and the language spec indicates that this may vary, but this
> > works with the standard
> <snip>
> > Doug Bell
> > db...@shvn.com
> >
> Interesting, but printStackTrace() doesn't work when using the Symantec JIT
> compiler.
> Don't know if that's a violation of the Java spec, but the availability of
> printStackTrace() is not something I'd want to rely on.
> I'd force the caller to provide his 'this'.
Doug Bell
(This is a repost of an article cancelled by the rogue canceller.)
D'Arcy Smith
Gordon McMillan wrote:
> Interesting, but printStackTrace() doesn't work when using the Symantec JIT
> compiler.
> Don't know if that's a violation of the Java spec, but the availability of
> printStackTrace() is not something I'd want to rely on.
> I'd force the caller to provide his 'this'.
I don't think it works with the Borland JIT either...
I wouldn't rely on printStackTrace being there...
You can turn off our JIT by pussing JAVA_COMPCMD=DIS
in your cafe\bin\sc.ini file.
..darcy
--
D'Arcy Smith
Symantec, Internet Tools