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

Mandy Chung mandy.chung at
Thu Jul 11 08:42:56 UTC 2013

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 
> openjdk 1.7.0_25 freezes 
> with 100% CPU load in this code: 
> 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:

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


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

More information about the core-libs-dev mailing list