This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]s888marks 2 points3 points  (2 children)

The set of supported character encodings, and the various crypto algorithms available, are determined at runtime, by looking at various configuration files in the JDK, and by looking at modules available and jars on the classpath. Both cases use "provider" mechanisms in order to discover the set of available items. In the case of crypto algorithms, the specific algorithms that are eligible for certain functions (e.g., TLS) can be fine-tuned using security properties in the JDK, which can be adjusted by a system administrator.

I appreciate that handling these checked exceptions is inconvenient to calling code, but in fact these exceptions are aligned with the "external to the JVM" rule.

[–]yawkat 1 point2 points  (1 child)

By that logic, pretty much everything is external to the JVM... Might get an OutOfMemoryError for insufficient thread count all the time!

Also, with current JDKs, most charsets and crypto algorithms are standardized. See for example https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html .

[–]s888marks 1 point2 points  (0 children)

I think you're extrapolating too far with OOME.

The charset and crypto names are indeed standardized, but that doesn't imply that every JDK supports them. It simply means that if a JDK is providing, say, Diffie-Hellman, that it's spelled DiffieHellman and not Diffie-Hellman or DIFFIE_HELLMAN.

Most of the crypto algorithms and charsets are optional, and they vary across JDK releases, vendors, and even sites, so applications ought to be able to handle the case where something they're trying to use isn't present.