The Java Cryptography Architecture (JCA) is Java’s standard framework for cryptographic interfaces, classes, and algorithm services. Application code uses this common API instead of depending directly on a particular cryptographic implementation. section 4.3
JCA uses a modular, provider-based design. Interfaces and classes in java.security and javax.crypto route requests to algorithm implementations installed in the Java Runtime Environment. This separation keeps application code independent of provider details and allows providers to offer different algorithm sets. section 4.3
The Java Cryptography Extensions (JCE) complement JCA with cryptographic implementations. Historically, export controls affected available algorithms and key strengths; Java 9 and later ship with unlimited-strength encryption. Bouncy Castle supplies an alternative provider with additional algorithms and embedded-device support. section 4.3
Hashing a file through JCA
A file hash can be calculated through the standard MessageDigest API without directly selecting a provider: MessageDigest.getInstance("SHA3-256").digest(data). The same refunds.json input produces the hexadecimal digest 542b49a04073502046b0de5751d5f7a9afe7c1ff2d63524c0863233a53de0c14. The provider supplies the implementation behind the API call. section 4.3
Figure 4.6 Application code calls the standard JCA and JCE APIs, making the code independent of the crypto algorithm implementation. The JCA and JCE layer routes calls to a provider’s implementation. Java 11-based OpenJDK ships with 13 providers out of the box.
A provider-routing diagram makes the separation between application code, standard JCA/JCE APIs, and cryptographic implementations immediately visible. section 4.3
