problems with sun.reflect.Reflection.getCallerClass(int)

[Mandy Chung]

Hi Jochen,

I read through the thread in mlvm-dev [1] that has a good discussion 
there.   I have filed a RFE:
    8020785: caller-sensitive methods to skip dynamic generated frames 
and look up the true caller

This seems that java.lang.instrument might be an appropriate place for 
this support.  This certainly requires further investigation.

Mandy

[1] http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-July/005387.html
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020785

On 7/11/2013 4:21 PM, Jochen Theodorou wrote:
> Hi all,
>
> I started a thread about this already on the mlvm list, but since I 
> get no responses there I am going to ask here as well. Plus I have an 
> actual problem with openjdk 7u25 related to this it seems.
>
> First the u25 problem. According to 
> https://jira.codehaus.org/browse/GROOVY-6246 openjdk 1.7.0_25 freezes 
> with 100% CPU load in this code: 
> https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/reflection/ReflectionUtils.java#L105
>
> This is surely not the nicest piece of code and all that, but that is 
> not the point. The point is that this worked in openjdk 1.7.0_9 and 
> does not in openjdk 1.7.0_25. Where it does work is in the oracle jdk 
> 1.7.0_25. Btw: it is too bad there are no .tar.gz packages of the 
> openjdk builds available. Assuming the diagnosis is right, this should 
> help pinpointing the problem. Has there been any changes already to 
> that method?
>
> Of course Reflection.getCallerClass(int) is a bigger problem for us. 
> It was announced, that in u40 of jdk 1.7.0 this method will be no 
> longer operational, unless you use a jvm switch. This is quite 
> troublesome for us, but at least there is some way. In jdk 1.8 this 
> method is supposed to disappear without replacement. There seems then 
> to be the getCallerClass() method, which ignores frames from 
> reflection (I strongly hope for you guys that lambda and indy are 
> included here), but this will not rescue us at all. We have almost 
> always a frame of our own appearing in a "first call" in Groovy. And 
> there is no way to avoid that (not even in indy). That means for us, 
> that any functionality depending on this cannot be called from a 
> Groovy program anymore. We already replace 
> RessourceBundle.getBundle(String) to let it discover the right loader. 
> But after the change this will not help. Transporting the not always 
> available caller class from the callsite into the method is for 
> current versions of Groovy (and all versions of Groovy are influenced 
> here)
>
> We are currently investigating if we can find a workaround for @Grab 
> (http://groovy.codehaus.org/Grape) in some cases. There won't be one 
> for all cases of course.
>
> What I would like to hear is a statement if this is taken as serious 
> or if it will be ignored. From the mlvm list I have so far the 
> impression, that it will be ignored.
>
>
> bye Jochen
>