Quarkus 2.x has java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.JceSecurity

Describe the bug

After upgrading from 1.13.7.Final to any of the 2.x versions we get this error at startup.

I retested with 2.1.1.Final and it has the same behavior.

We are using JDK 11.0.11+9. Code and JDK work fine with pre 2.x Quarkus.

This code is just trying to decrypt a password in the io.quarkus.credentials.CredentialsProvider implementation used to connect to the database.

2021-08-05 15:21:21,296 ERROR [io.qua.run.Application] (main) Failed to start application (with profile prod): java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.JceSecurity at java.base/javax.crypto.Cipher.getInstance(Cipher.java:540) at com.bs.util.encryption.AESEncryptDecrypt.getInitializedCipher(AESEncryptDecrypt.java:151) at com.bs.util.encryption.AESEncryptDecrypt.decrypt(AESEncryptDecrypt.java:127) at com.bs.util.encryption.AESEncryptDecryptProxy.decrypt(AESEncryptDecryptProxy.java:44) at com.bs.util.BSDataSourceCredentialsProvider.getCredentials(BSDataSourceCredentialsProvider.java:33) at com.bs.util.BSDataSourceCredentialsProvider_ClientProxy.getCredentials(BSDataSourceCredentialsProvider_ClientProxy.zig:157) at io.quarkus.agroal.runtime.AgroalVaultCredentialsProviderPassword.asProperties(AgroalVaultCredentialsProviderPassword.java:21) at io.agroal.api.security.AgroalDefaultSecurityProvider.getSecurityProperties(AgroalDefaultSecurityProvider.java:23) at io.agroal.pool.ConnectionFactory.securityProperties(ConnectionFactory.java:190) at io.agroal.pool.ConnectionFactory.securityProperties(ConnectionFactory.java:179) at io.agroal.pool.ConnectionFactory.jdbcProperties(ConnectionFactory.java:160) at io.agroal.pool.ConnectionFactory.createConnection(ConnectionFactory.java:204) at io.agroal.pool.ConnectionPool$CreateConnectionTask.call(ConnectionPool.java:470) at io.agroal.pool.ConnectionPool$CreateConnectionTask.call(ConnectionPool.java:452) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at io.agroal.pool.util.PriorityScheduledExecutor.beforeExecute(PriorityScheduledExecutor.java:68) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1126) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829)

Expected behavior

Quarkus should be able to load the JDK class javax.crypto.JceSecurity.

Actual behavior

See stacktrace in description.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

openjdk 11.0.11 2021-04-20 OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9) OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.1.1.Final

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[stuartwdouglas]

I have opened https://github.com/agroal/agroal/pull/39

[jaikiran]

A java.lang.Error that gets thrown from a static initialization block of a class doesn’t seem to raise a ExceptionInInitializerError. Instead it just throws back the Error. This is unlike the case where an java.lang.Exception gets thrown from a static initialization block, where such exceptions are wrapped into ExceptionInInitializerError. I actually tried this again in that trivial Java code I pasted previously and threw an Error from Bar instead of an Exception and running it I see that it just throws the original Error and doesn’t wrap it into a ExceptionInInitializerError. So that explains why the ExceptionInInitializerError byteman rule didn’t get triggered in this flow. The javadoc of ExceptionInInitializerError makes no distinction between these 2 cases, so again this needs some inputs from the JDK team.

I read up the JLS and section 12.4.2[1] states:

Otherwise, the initializers must have completed abruptly by throwing some exception E. If the class of E is not Error or one of its subclasses, then create a new instance of the class ExceptionInInitializerError, with E as the argument, and use this object in place of E in the following step

So the current behaviour is as per the spec, so there’s no issue in this area.

I see that Stuart has opened a PR to fix agroal to log these exceptions that fall off the thread execution. So that should sort out the major part of this issue. The only final question is, should we improve the ApplicationLifeCycleManager to log the whole exception stacktrace instead of just the rootCause.

[1] https://docs.oracle.com/javase/specs/jls/se16/html/jls-12.html#jls-12.4.2