Description of problem: I develop web applications using grails. When I try to run my application, I get the following exception: NoSuchMethodError: sun.reflect.Reflection.getCallerClass(I)Ljava/lang/Class; Version-Release number of selected component (if applicable): java-1.7.0-openjdk-1.7.0.25-2.3.10.3.fc18 Additional info: This error is related to a recent change in the jdk, but grails/spring developpers are aware of the problem and provided a patch that works whe using oracle jdk1.7u25 ( see http://jira.grails.org/browse/GRAILS-10183#comment-75788 ). However, there is a remaining problem in the fedora provided openjdk (based on icedtea): it laks some commits from oracle. The jdk commit that removed the getCallerClass method is: 8010118: Annotate jdk caller sensitive methods with @sun.reflect.CallerSensitive http://hg.openjdk.java.net/jdk7u/jdk7u-gate/jdk/rev/9603e9d828c4 But the method was reintroduced with 8014745: Provide a switch to allow stack walk search of resource bundle http://hg.openjdk.java.net/jdk7u/jdk7u-gate/jdk/rev/9603e9d828c4 oracle's update 25 contains that last patch but not the latest icedtea-forest. I suppose the icedtea-forest should be synced with the latest openjdk release.
AFAIK you are right. The issue is that Oracle do not keep us in loop as is necessary - so yes,sorry to say it, but blame them :( This will be fixed on icedtea level asap. But I'm afraid it will take some time before it reach repos. Deep sorry for the breakage.
Thanks for your support. I just did a simple downgrade (and I can also use the Oracle jdk if necessary), this solves the immediate problem. In the mean time, I will also try to find a way to get spring-loaded work with the new api; it will be usefull for jdk8 and probably jdk7u40.
The same patch is necessary to keep OSGi applications such as JBoss AS working (I think), so it would be good if you could get this in soon.
You should resync your Fedora packages with the tag used by IcedTea for the upcoming 2.3.10 release. In future, as Fedora doesn't use IcedTea, I strongly suggest that it adds its own tags and naming, so as not to confuse its packages with the potentially different upstream IcedTea release.
Fedora 18 have already received fixed b25 (based on 2.3.10 Andrew is linking, so issue should be fixed. f17 and f19 are still in testing repo.
Created attachment 767436 [details] Simple test case I'm testing the latest fedora build (fedora-2.3.10.4.fc18-x86_64) and there is still a problem. Here is the output of my simple test case while using the latest fedora jdk: $ java -ea TestMe getCallerClass(0) => TestMe getCallerClass(1) => TestMe getCallerClass(2) => TestMe getCallerClass(3) => TestMe Exception in thread "main" java.lang.AssertionError at TestMe.getCaller(TestMe.java:18) at CallingClass.methodCall(TestMe.java:8) at TestMe.main(TestMe.java:22) When run with latest oracle jdk: $ ~/dev/jdk1.7.0_25/jre/bin/java -ea TestMe getCallerClass(0) => sun.reflect.Reflection getCallerClass(1) => sun.reflect.Reflection getCallerClass(2) => TestMe getCallerClass(3) => CallingClass It seems the getCallerClass method exists but it ignores the given depth parameter. As a consequence of this, grails app are not working as already reported.
Re-opening as the problem is not solved; see attached test case.
I am unable to reproduce this: $ java -version java version "1.7.0_25" OpenJDK Runtime Environment (fedora-2.3.10.4.fc18-x86_64) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) $ java TestMe getCallerClass(0) => TestMe getCallerClass(1) => TestMe getCallerClass(2) => TestMe getCallerClass(3) => TestMe Can you please paste the output of java -version?
Doh, nvm. I was on the lookout for the exception -- just realized that the actual caller differs to. Please ignore comment 8.
If you want to reproduce the exception, you have to enable assertions with the -ea flag.
We are going to test https://koji.fedoraproject.org/koji/buildinfo?buildID=431189, to exclude packaging error. If you find free cycles, you may try too.
I just dowloaded the build, result for the test case below; same problem as before. $ java -version java version "1.7.0_25" OpenJDK Runtime Environment (fedora-2.3.10.7.fc18-x86_64) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) $ java -ea TestMe getCallerClass(0) => TestMe getCallerClass(1) => TestMe getCallerClass(2) => TestMe getCallerClass(3) => TestMe Exception in thread "main" java.lang.AssertionError at TestMe.getCaller(TestMe.java:18) at CallingClass.methodCall(TestMe.java:8) at TestMe.main(TestMe.java:22)
Jiri, Do we know what the issue here is?
FWIW, I can confirm this regression is fixed as of java-1.7.0-openjdk-1.7.0.25-2.4.1.0.el6 for RHEL. I traced an OpenShift user application issue back to the regression (the application ended up wedged and CPU-pegged due to log4j 2.x's use of the private API; my write-up is here: https://gist.github.com/ironcladlou/6117383). Related OpenShift-specific bugs are 990564 and 984765. Not sure if this information is of any value, but I figured it couldn't hurt to chime in. Thanks to Jiri for putting together the new package!
Thanks for replying back Dan! I will close this one then.
Sorry, but I think this bug should not be closed, as it was opened against Fedora 18 and the java-1.7.0-openjdk-1.7.0.25-2.4.1.0 pakage is not currently available in koji. The bug is still there in Fedora 18 and 19.
Doh. You are absolutely right. Sorry, I did not notice the Fedora in the component.
The problem is there is no "openjdk release". There hasn't been one since August 2012. What we can do, now we know the change concerned, is manually backport that change and do a 2.3.13 release with it. However, the underlying problem here is Oracle's release management of 7u, both in their refusal to release security updates and including this change in their proprietary u25 but not OpenJDK u25. http://mail.openjdk.java.net/pipermail/jdk7-dev/2013-August/002336.html
The problem is due to the version of 8010118 which was received from Oracle for this update. It differs from the one posted upstream and, as a result, a merge error has occurred: diff --git a/src/share/native/sun/reflect/Reflection.c b/src/share/native/sun/reflect/Reflection.c --- a/src/share/native/sun/reflect/Reflection.c +++ b/src/share/native/sun/reflect/Reflection.c @@ -37,9 +37,7 @@ JNIEXPORT jclass JNICALL Java_sun_reflect_Reflection_getCallerClass0 (JNIEnv *env, jclass unused, jint depth) { - // Until there is hotspot @CallerSensitive support, - // depth must always be 2 to get the immediate caller - return JVM_GetCallerClass(env, 2); + return JVM_GetCallerClass(env, depth); } JNIEXPORT jint JNICALL Java_sun_reflect_Reflection_getClassAccessFlags That body is appropriate for the version that doesn't take a depth argument, but not the one that does...
java-1.7.0-openjdk-1.7.0.25-2.3.12.2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/java-1.7.0-openjdk-1.7.0.25-2.3.12.2.fc18
Package java-1.7.0-openjdk-1.7.0.25-2.3.12.2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing java-1.7.0-openjdk-1.7.0.25-2.3.12.2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15139/java-1.7.0-openjdk-1.7.0.25-2.3.12.2.fc18 then log in and leave karma (feedback).
These seem to have the same cause: http://jira.codehaus.org/browse/GROOVY-6246 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016814
Tested the latest fedora-update build and stil lthe same problem. $ java -version java version "1.7.0_25" OpenJDK Runtime Environment (fedora-2.3.12.2.fc18-x86_64) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) $ java -ea TestMe getCallerClass(0) => TestMe getCallerClass(1) => TestMe getCallerClass(2) => TestMe getCallerClass(3) => TestMe Exception in thread "main" java.lang.AssertionError at TestMe.getCaller(TestMe.java:18) at CallingClass.methodCall(TestMe.java:8) at TestMe.main(TestMe.java:22)
Tested on Fedora 19 with the latest package: fedora-2.3.12.4.fc19-x86_64 and works as before. It seems there is a difference between the fc18 and fc19 builds.
Created attachment 790433 [details] Updated test case that supports pre update 25 jdk versions. Run with java -ea TestMe Works with fedora19 jdk version java-1.7.0-openjdk-1.7.0.25-2.3.12.4.fc19.x86_64 Does not work with fedora18 jdk version java-1.7.0-openjdk-1.7.0.25-2.3.12.2.fc18
Package java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15139/java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc18 then log in and leave karma (feedback).
java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.