RFR: 8298420: PEM API: Implementation (Preview) [v15]

[Sean Mullan]

On Thu, 8 May 2025 20:58:41 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/PEMEncoder.java line 54:
>> 
>>> 52:  * and footer.
>>> 53:  *
>>> 54:  * <p> Encoding may be performed on Java Cryptographic Extension (JCE) objects
>> 
>> Is "JCE objects" a formal term? We used to say "JCA and JCE". How do we call them now?
>
> I'd like to keep the JCA/JCE nuance out.  I'd rather just leave it as is, or use the alternative I've used elsewhere, Java API cryptographic object.

I would probably just say "cryptographic objects that implement `DEREncodable`"

>> src/java.base/share/classes/java/security/PEMEncoder.java line 70:
>> 
>>> 68:  * {@linkplain PEMRecord#pem()} with a generated the PEM header and footer
>>> 69:  * from {@linkplain PEMRecord#type()}.  It will not check the validity of
>>> 70:  * the data.
>> 
>> Since you mention `PEMRecord` specifically, I'd see the clarification that the `leadingData` there will not be encoded. Otherwise, you cannot guarantee on the encoding.
>
> I think specifying the fields that are encoded makes it clear what is not in the encoding.

I would have expected the leading data to be encoded. Why is the leading data not encoded?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085594839
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085615501