see http://mindprod.com/jgloss/trace.html

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.

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.