On Thu, 9 Oct 2025 05:00:45 GMT, Anthony Scarpino <[email protected]> wrote:
>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line
>> 565:
>>
>>> 563: */
>>> 564: @PreviewFeature(feature = PreviewFeature.Feature.PEM_API)
>>> 565: public KeyPair getKeyPair(char[] password) throws
>>> GeneralSecurityException {
>>
>> This should specifically throw an `InvalidKeyException` if decryption fails.
>> I think you want to specify the exact subclasses when it is clearly the
>> right behavior. In this case, the method should always throw
>> `InvalidKeyException` on decryption errors.
>>
>> Also why generalize it to throw `GeneralSecurityException`? This should
>> throw the same exceptions as `getKeySpec(Key, Provider)` since the params
>> are the same.
>
> Sure, not specifying InvalidKeyException for non-KeyPair return cases in the
> javadoc is an oversight. Underneath the code, the `InvalidKeyException` and
> `NoSuchAlgorithmException` were always thrown, it's the method signature that
> is different. Documenting `getKeyPair()` that NSAE and IKE are thrown.
> Essentially, I'd replace `@throws GeneralSecurityException ...` with `@throws
> InvalidKeyException ...`.
>
> I think it is user-friendly to have GSE on the method signature. Specifying
> `NoSuchAlgorithmException` in the method signature I don't think offers value
> and is purely informative. Since the algorithm is determined by the encoding
> and cannot be influenced by either getKeyPair method.
>
> `getKeySpec()` has generalized its exception handling by wrapping
> `IllegalBlockSizeException` and `BadPaddingException` into
> `InvalidKeyException`. The `getKeySpecImpl()` method that all
> the`getKeySpec()` methods call, wrap `GeneralSecurityException` and
> `IOException` into `InvalidKeyException`.
I'm changed the throws to NASE and IKE
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2445839787
