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

[Mandy Chung]

Hi Jochen,

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?
>

There is a regression in 7u25 that is fixed in 7u40:
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016814

The workaround is to call it with depth+1 when running in 7u25.  I will 
reply the second part next (currently OOTO).

Mandy

> 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
>