In working on a different problem (related to RMI), I upgraded the system's "security folder" with the "unlimited strength" policy files and now my applicaiton fails in a different way. I get a long stack dump, of which following bits appear pertinent:
Exception in thread "main" java.lang.ExceptionInInitializerError [...crop...] Caused by: java.lang.SecurityException: Can not initialize cryptographic mechanism at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:86) ... 17 more Caused by: java.lang.SecurityException: The jurisdiction policy files are not signed by a trusted signer! [...crop...]
Um, WTF? The ONLY change was that I moved the orignal jar files aside and added the unlimited ones in $JAVA_HOME/lib/security. That directory now looks like this:
$ ls blacklist javaws.policy trusted.libraries cacerts local_policy.jar US_export_policy.jar java.policy local_policy.jar.strong US_export_policy.jar.strong java.security local_policy.jar.unlimited US_export_policy.jar.unlimited
Of course, the .strong and .unlimited version are there so I can switch back quickly.
The directions were short and plain, and it would appear that they ONLY envision the replacement of these two files (local_policy.jar and US_exportpolicy.jar).
What else is there to do?
Note that the versions of java and the policy files are the very youngest to date: 1.7.0_03, and jce_policy-6, respectively.
P.S. The article of similar title, found here, was of no help at all.
Rather than mixing runtime and policy file versions, you should use the policy files for Java 7.
This happens when Java version does not match with the version of policy files. You can download the relevant policy files from following links.
Policy jars for Java 8
Policy jars for Java 7
Policy jars for Java 6
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With