Roman Kennke wrote: > I also don't think I misunderstood the purpose of the VMStackWalker VM > interface. As far as I understand it, this interface is there in order > to provide more efficient access to stack information than > Thread.getStackTrace(). Tom's proposal was about VMStackWalker.getCallingClass[Loader](), which is used in Class.getClassLoader and most of the reflection methods. This is a very specific use case and very performance critical, therefore they deserve their own APIs. Apart from that there is also getContext, which (as you note) is horribly slow but AFAIK not used in any performance critical code. > For pre-1.5 this is the only way for library > code to access stack info. Or am I completely wrong here? In Classpath > it is only used in java.lang.Security and gnu.CORBA.ObjectCreator > telling by a quick Eclipse search. Both could well (or even > better) live with an iterator-type interface. The problem with an interator type interface is that it is much harder to define it to be both portable and efficient. This doesn't mean that I'm against it, just that will be a lot of effort to define it and as of yet I haven't seen a clear need to do so. > And as I said before, logging could be made alot faster, when we > didn't have to create a complete stacktrace for every logging entry. I understand, but if this is the only use case, we're better off with a new method dedicated to this purpose, because that will be much easier to design/implement (and is also what I gather from your previous is what you have done). Regards, Jeroen
