java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.JceSecurityManager

Question

java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.JceSecurityManager
    javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2543)
    java         


        

Answer 1

Make sure the following files on executing JRE is NOT corrupted/modified/deleted.

• jre\lib\security\local_policy.jar
• jre\lib\security\US_export_policy.jar

I had a similar issue which was caused by manually copying these two files from different java version. Resolved after replacing with original files.

Answer 2

I hit this when trying to run Maven in the library/openjdk:9 Docker container. I resolved it the same way as other commenters here, by getting a Java 9 JDK from Oracle at https://jdk9.java.net/download/ and setting JAVA_HOME. It seems that these two jar files (mentioned in other answers) aren't present in the Docker image.

Answer 3

If you are using Java 8 Update 151 (8u151) or later, also check this:

New Features New Security property to control crypto policy

This release introduces a new feature whereby the JCE jurisdiction policy files used by the JDK can be controlled via a new Security property. In older releases, JCE jurisdiction files had to be downloaded and installed separately to allow unlimited cryptography to be used by the JDK. The download and install steps are no longer necessary. To enable unlimited cryptography, one can use the new crypto.policy Security property. If the new Security property (crypto.policy) is set in the java.security file, or has been set dynamically by using the Security.setProperty() call before the JCE framework has been initialized, that setting will be honored. By default, the property will be undefined. If the property is undefined and the legacy JCE jurisdiction files don't exist in the legacy lib/security directory, then the default cryptographic level will remain at 'limited'. To configure the JDK to use unlimited cryptography, set the crypto.policy to a value of 'unlimited'. See the notes in the java.security file shipping with this release for more information.

Note: On Solaris, it's recommended that you remove the old SVR4 packages before installing the new JDK updates. If an SVR4 based upgrade (without uninstalling the old packages) is being done on a JDK release earlier than 6u131, 7u121, 8u111, then you should set the new crypto.policy Security property in the java.security file.

Because the old JCE jurisdiction files are left in /lib/security, they may not meet the latest security JAR signing standards, which were refreshed in 6u131, 7u121, 8u111, and later updates. An exception similar to the following might be seen if the old files are used:

Answer 4

Try the following steps:

1. Uninstall all old versions of Java, and keep only one version(preferably latest version of JDK)
2. If manual entries of old java environment path is set, remove them eg) JAVA_HOME, PATH
3. Point the IDE (eg. Eclipse) to the latest version of JDK
4. Revert to original jar files in the JDK/JRE if modified earlier by manual steps
5. Click 'Check of update' from java installation on the system/PC

Answer 5

This happened to me when I was trying to connect to a DB with IntelliJ 14.

I had played around with my jre\lib\security\local_policy.jar and jre\lib\security\US_export_policy.jar files

I fixed this by:

1. Installing a new JDK
2. Pointing IntelliJ to use this new JDK
3. Setting JAVA_HOME to this new JDK
4. Restart IntelliJ