On Fri, 1 May 2026 18:10:13 GMT, Weijun Wang <[email protected]> wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> withFactoriesOf
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 71:
>
>> 69: *
>> 70: * <p> For {@code PublicKey} and {@code PrivateKey} types,
>> algorithm-specific
>> 71: * subclasses are returned if supported, such as {@code ECPublicKey} or
>
> Is this always true?
If an EC key is decoded, it will return the underlying EC key implementation
that implements the EC interface.
> src/java.base/share/classes/java/security/PEMDecoder.java line 136:
>
>> 134: * @implNote This implementation decodes non-encrypted RSA PRIVATE KEY
>> as {@code PrivateKey},
>> 135: * X509 CERTIFICATE and X.509 CERTIFICATE as {@code X509Certificate},
>> and CRL as
>> 136: * {@code X509CRL}. Other implementations may recognize additional PEM
>> types.
>
> I am not sure what "additional PEM types" mean here. We certainly cannot
> decode to other types because `BinaryEncodable` is sealed. If you mean decode
> to `PEM`, that's already described above ("no corresponding class") and it
> does not belong to an `@implNote`.
>
> This also appears in `PEMEncoder`.
An implementation could support `EC PRIVATE KEY` and still be in the sealed
interface.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r3174771817
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r3174796389
