On Wed, Jul 10, 2013 at 4:30 AM, Cédric Champeau <cedric.champ...@gmail.com> wrote: > I must second Jochen here. That getCallerClass doesn't work anymore in > an update release is unacceptable to me. As Jochen explained, there's no > suitable replacement so far. We can live with getCallerClass > disappearing if there's a replacement, but obviously, the > @CallerSensitive "solution" is not one for us. There are additional > frames in our runtime. Also we need to support multiple JDKs (5 to 8, > but 8 is already broken). Especially, we don't have any replacement for > @Grab which makes use of it internally. Furthermore, I suspect > Class.forName and ResourceBundle.getBundle are widespread in user code > and it used to work. This is not the kind of stuff that people expect to > break when upgrading a JDK, and we can't tell them to rewrite their code > (especially, finding the right classloader might involve more serious > refactoring if it needs to be passed as a method argument).
Another alternative we are not using in JRuby...but we could. In JRuby, we pass the calling object into every call site to check Ruby-style visibility at lookup time (we can't statically determine visibility, and we do honor it). That gets you a bit closer to being able to get the caller's classloader without stack tricks (though I admit it does nothing for methods injected into a class from a different classloader). On Wed, Jul 10, 2013 at 4:40 AM, Noctarius <m...@noctarius.com> wrote: > Maybe a solution could be an annotation to mark calls to not > appear in any stacktrace? Personally, I'd love to see *any* way to teach JVM about language-specific stack traces. Currently JRuby post-processes exception traces to mine out compiled Ruby lines and transform interpreter frames into proper file:line pairs. A way to say "at this point, call back my code to build a StackTraceElement" would be very useful across languages. Of course, omitting from stack trace has very little to do with stack-walking frame inspection tricks like CallerSensitive. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
