Le 11/07/2013 06:09, Charles Oliver Nutter a écrit :
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.
+1 the solution to annotate classes so that they are "transparent" to
the stack frames, combined with @CallerSensitive, is likely to fix our
problem (unless Jochen remembers if there was really a problem with it).
But that's the future.
We're facing a serious problem: we already have a bug report using
openjdk 1.7.0_25, and if the removal is really intended to go into
1.7u40, Groovy will just be broken. This is something that needs to be
considered seriously. For example, @Grab, our dependency download tool
which works in scripts depends on getCallerClass. It's a major feature
that would be broken. The bug I'm talking about which has been reported
a few days ago is about ResourceBunder.getBundle which nows trigger an
infinite loop if used in Groovy. (Unfortunately, we couldn't reproduce
locally since we need to build an older jdk version, this takes a bit of
time). We are really happy to discuss an alternative for JDK 8, but it's
too soon to remove in JDK7, because as we said, there's no alternative!
The only reasonable explanation I can find for removing
getCallerClass(int) from JDK 1.7u40 is a major security issue. If
there's not, please reconsider it, or Groovy will be broken (if anyone
sees how we can replace it today with a solution that would work on jdks
5 -> 7, we're happy to consider it). There are lots of applications in
production with Groovy and Grails and starting to see them fail after a
JDK update would be a total disaster.
Thanks!
--
Cédric Champeau
SpringSource - Pivotal
http://www.springsource.org/
http://www.gopivotal.com/
http://twitter.com/CedricChampeau
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
