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

Jochen Theodorou blackdrag at gmx.org
Thu Jul 11 08:21:30 UTC 2013


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

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




More information about the core-libs-dev mailing list