Well a StackTraceElement gives you a class name and a method name. You'd need a class loader to resolve these into a java.lang.reflect.Method object... Oh, and a method signature in case the method name is overloaded, as there's no reflection API for method lookup by line number.
So, it's unfortunately not too helpful for this use... Attila. On 2008.01.09., at 9:33, Ted Neward wrote: > > You can already get an array of StackTraceElements, each of which > can give > you the Method that was invoked.... > > > I take it you want *mutable* access to the stack? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: [email protected] [mailto:jvm- >> [EMAIL PROTECTED] On Behalf Of Don Schwarz >> Sent: Tuesday, January 08, 2008 9:30 AM >> To: [email protected] >> Subject: [jvm-l] Re: A better solution for artificial call frames? >> >> >> On Jan 7, 2008 7:24 AM, Kresten Krab Thorup <[EMAIL PROTECTED]> wrote: >>> >>> Another aspect is, that frames are the only kind of object reference >>> source which is not accessible by reflection. Having some kind of >>> reflective access to this would allow several new behaviors in the >>> meta layers. >>> >> Agreed. >> >> Even just being able to get a stack of Method objects for a thread >> would be useful in many situations, especially when tied to >> reflection >> of Method annotations. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
