The current specification for Cipher.getInstance(String transformation, String provider) lists the following exceptions:

NoSuchAlgorithmException – if the transformation is null, empty, in an invalid format, or if a CipherSpi implementation for the specified algorithm is not available from the specified provider.

NoSuchPaddingException – if the transformation contains a padding scheme that is not available.

However, this distinction can be ambiguous in practice and leads to potentially confusing behavior. For example, when the transformation includes a padding scheme (e.g., "AES/CBC/PKCS5Padding_NoSuchPadding") that is not supported by the provider, a NoSuchAlgorithmException may be thrown instead of the expected NoSuchPaddingException.

This happens when the provider does not register a CipherSpi implementation for the specific transformation (including the unsupported padding). As a result, the transformation as a whole is not recognized, and the lookup fails early with a NoSuchAlgorithmException, even though the cause is actually the unsupported padding scheme.

This behavior is provider-specific, and the observed exception may differ depending on whether:

The provider parses the transformation format into algorithm/mode/padding components, or

It requires an exact match for the transformation string in its registered services.

Suggested Specification Clarification:
Update the NoSuchPaddingException javadoc to clarify that the actual exception thrown depends on how far the provider parses the transformation:

NoSuchPaddingException – if the transformation specifies a padding scheme that is not available and the provider recognizes the transformation format up to the padding component. In cases where the provider does not recognize the full transformation string (e.g., due to an unsupported padding scheme), a NoSuchAlgorithmException may be thrown instead.

This clarification makes it clear that the distinction between these exceptions is contextual and influenced by provider behavior, avoiding confusion for developers interpreting these errors.