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

[Attila Szegedi]

FWIW, I'm currently working on Dynalink correctly supporting methods that are marked with @CallerSensitive; My tests from Nashorn show things work as expected, i.e. you can give some permissions to your script based on its URL in the security policy, and e.g. invoking AccessController.doPrivileged() through INVOKEDYNAMIC works as expected; it is actually a pretty big deal getting this to work right :-) (doPrivileged, of course, being @CallerSensitive).

Attila.

On Jul 2, 2013, at 2:56 PM, Jochen Theodorou <blackdrag at gmx.org> wrote:

> Hi all,
> 
> """The Oracle JDK internal method sun.reflect.Reflection.
> getCallerClass(int) is planned to be disabled in Oracle JDK 7u40. It is 
> considered for removal in a later 7 update release.
> 
> As you may be aware, the Oracle JDK internal 
> sun.reflect.Reflection.getCallerClass(int) method has been removed from 
> JDK 8. [1]
> The method is also planned [2] to be disabled in the 7u40 release. A 
> call to the method would then trigger an UnsupportedOperationException."""
> 
> That means the method will be fully away for jdk8 and is going away in 
> 7u40, but can still be enabled by a command line switch. There is a 
> @CallSensitve annotation which allows calling Reflection.getCallerClass().
> 
> But this is causing some problems for us actually. Even if 
> Reflection.getCallerClass() is ignoring all frames added by reflection 
> (what about those added by invokedynamic/lambda?), it is not enough for 
> us, since we will have also runtime generated classes appearing in there.
> 
> A simple example is a Groovy program calling 
> ResourceBundle#getBundle(String). While in non-indy mode the first 
> access from that call site may be done by reflection and then work, 
> subsequent calls would be done with runtime generated classes and then 
> it can stop working very fast. Another one is Groovy grapes, which add 
> libraries to the classpath at runtime, and it depends on being able to 
> get the caller class loader for that. The usual depths here are 3-4, and 
> that means 3-4 frames, that are not our callsite caching or indy, or 
> reflection.
> 
> With the runtime generated classes in the way I am not sure we can 
> resolve the issue without really major changes, or we simply say that 
> Groovy 2.x and earlier may not properly work on post jdk 7u40... unless 
> you use indy, where I would still need confirmation there are no frames 
> in the way from that then.
> 
> I imagine other languages will have similar problems here and there... 
> or not?
> 
> bye Jochen
> 
> -- 
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev