sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?

[Cédric Champeau]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130711/914f2cb4/attachment.html