Not usually, at least not for Java compiled by a compiler which obeys the JLS
(there are other sources of legal bytecode, of course).  The full rules are set
out in section 13.1 of the JLS (part of the binary compatibility stuff).
Ignoring various complications, the rule is that the class name is the name of
the type of the expression whose value is the target of the method invocation
(any kind of method invocation).  That is /unless/ the method is one of the
methods defined by Object, in which case the class name is required to be
Object.

So in your example, if you had declared your two variables to have type
java.lang.Exception then the invokevirtual would invoke java/lang/Exception
printStackTrace()V.  If you had declared e1 as a java.lang.Throwable then the
invokevirtual would name that class instead.  OTOH,
equals:(Ljava/lang/Object;)Z is defined by Object, so any invocation of that
method must name java/lang/Object.

I have, by the way, no idea at all what benefit there is supposed to be in
making java.lang.Object a special case.  I suspect there is none...

   -- chris

The parameter and return types must always match. Working out which
overloaded method to use is done at compile time. In 1.5+, the compiler
synthesises bridge methods for covariant return types.

Which class the method is declared on is not important. Indeed binary
compatibility requires that a method may be moved to a super class.

For methods declared in interfaces, it is preferable to use a class type
if possible because dispatch on a class type is often faster than on an
interface type.

Tom Hawtin