problems with sun.reflect.Reflection.getCallerClass(int)
mandy.chung at oracle.com
Thu Jul 11 08:42:56 UTC 2013
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:
> 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
> 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
More information about the core-libs-dev