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