LuciferYang commented on PR #43467: URL: https://github.com/apache/spark/pull/43467#issuecomment-1773971446
Yes, it has never been supported. However, this does not prevent Apple Silicon from using `JavaCryptoRandom`. The original logic was that as long as either `OpenSslCryptoRandom` or `JavaCryptoRandom` initializes successfully, it would be acceptable. But in 1.2.0, if `OpenSslCryptoRandom` fails to initialize, it directly fails. I suspect the change in behavior comes from this logic added in 1.2.0: https://github.com/apache/commons-crypto/blob/c5d19d017d96e34a4589736aeb48bc1d59e204a6/src/main/java/org/apache/commons/crypto/random/OpenSslCryptoRandom.java#L62-L72 <img width="633" alt="image" src="https://github.com/apache/spark/assets/1475305/e32602fc-061b-4123-a8e9-3fcc472a37c0";> The `initException` mechanism should be reused here instead of throwing an `RuntimeException`, because `RuntimeException` will also be wrapped into `ExceptionInInitializerError` by Java's own mechanism. This will cause the upper layer in 1.20 to be unable to handle this Error and continue to throw it up, which is the failure we are seeing now. <img width="914" alt="image" src="https://github.com/apache/spark/assets/1475305/0ebfe296-841c-452c-8aa9-a83ee41775d6";> However, since the `commons-crypto` project cannot be compiled on Apple Silicon, and I currently only have Apple Silicon development machines at hand, I am temporarily unable to verify this guess. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
