Andrew Haley wrote:
Tom Tromey writes:
> This week I spent some time looking at the libgcj/Classpath merge
> situation. After removing all the simple merges that hadn't yet been
> handled for some reason, I looked at VMStackWalker a little.
>
> I think this merge could be done fairly simply. In fact I think it
> just requires adding a 'Class' argument to
> VMStackWalker.getCallingClass and VMStackWalker.getCallingClassLoader.
> This argument would name the immediate caller, and these methods
> would be changed to return the class just above the argument class in
> the stack trace.
I think this is a bug. In the API spec, when the caller is wanted it
is the immediate caller -- the calling method, not the calling class.
We shouldn't be walking backwards until we see a different class.
GetCallingClass(Class) is intended for situations where you really want
the caller of an external API into the class, but due to overloaded
methods or inlining may have an indeterminate number of frames between
the external method and the site at which GetCallingClass() is called.
java.lang.reflect and ResourceBundle are two examples where it is useful
- we never want ResourceBundle.class or Field.class, for example, to be
returned there.
So, I don't think GetCallingClass(Class) is a bug - in fact it is
important, because implementing the same functionality becomes more
complicated and error-prone without it. You do of course need to be
careful with where it is used, but that is also going to be the case
with any alternative.
In the case of gcc.gnu.org/PR27352, I think the problem is simply that
Class.getClassLoader() is used internally within Class itself - we
should be using getClassLoaderInternal(). I'm testing a patch.
Bryce
