On Jul 11, 2013, at 10:30 AM, Christian Thalinger <christian.thalin...@oracle.com> wrote:
> > On Jul 11, 2013, at 12:35 AM, Cédric Champeau <cedric.champ...@gmail.com> > wrote: > >> 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! > > If the patch ends up in 7u40 then there will be a property or command line > switch to turn it back on for applications which just can't live without it. Here is the CR btw.: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014925 -- Chris > There is plenty of time to figure something out until 8. > > This mailing list is perhaps not the right list to express your concerns. > I'm not sure if you've already done this but you might think about posting to > jdk7u-dev. > > -- Chris > >> >> 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 > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
