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

[Christian Thalinger]

On Jul 11, 2013, at 12:35 AM, Cédric Champeau <cedric.champeau at 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.  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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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