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
