On Wed, 17 Sep 2025 01:00:21 GMT, Anthony Scarpino <[email protected]> wrote:
>> Hi >> >> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the >> PEM API. The most significant changes from [JEP >> 470](https://openjdk.org/jeps/470) are: >> >> - Renamed the name of `PEMRecord` class to `PEM`. >> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` >> class to accept `DEREncodable` objects rather than just `PrivateKey` objects >> so that cryptographic objects with public keys, i.e., `KeyPair` and >> `PKCS8EncodedKeySpec`, can also be encrypted. >> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the >> encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects. >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one > additional commit since the last revision: > > rework test & commented out code. src/java.base/share/classes/java/security/PEM.java line 40: > 38: * Mail (PEM) data by its type and Base64 content. > 39: * > 40: * <p> Methods {@link PEMDecoder#decode(String)} and Suggest rewording as "The {@link PEMDecoder#decode(String)} and {@link PEMDecoder#decode(InputStream)} methods ..." src/java.base/share/classes/java/security/PEM.java line 42: > 40: * <p> Methods {@link PEMDecoder#decode(String)} and > 41: * {@link PEMDecoder#decode(InputStream)} return a {@code PEM} object > when no > 42: * cryptographic object is available to represent the data type. "is available" sounds a bit odd. Maybe "when the data type cannot be represented by a cryptographic object". src/java.base/share/classes/java/security/PEM.java line 43: > 41: * {@link PEMDecoder#decode(InputStream)} return a {@code PEM} object > when no > 42: * cryptographic object is available to represent the data type. > 43: * If {@code PEM} is desired instead of an available cryptographic object, "available" again sounds odd, I would just remove that word. src/java.base/share/classes/java/security/PEM.java line 44: > 42: * cryptographic object is available to represent the data type. > 43: * If {@code PEM} is desired instead of an available cryptographic object, > 44: * decoding methods {@link PEMDecoder#decode(String, Class)} or s/decoding/the decoding/ src/java.base/share/classes/java/security/PEM.java line 52: > 50: * > 51: * <p> When constructing a {@code PEM} instance, {@code type} and > 52: * {@code content} may not be {@code null}. s/may not/must not/ src/java.base/share/classes/java/security/PEM.java line 63: > 61: * PRIVATE KEY, ENCRYPTED PRIVATE KEY, RSA PRIVATE KEY, or PUBLIC KEY. > 62: * > 63: * <p> {@code leadingData} may be null if no non-PEM data preceded PEM > header Suggest rewording as "... if there was no data preceding the PEM header ..." Why do you allow null when there is a ctor that does not have a `leadingData` parameter - is there a reason for this? src/java.base/share/classes/java/security/PEM.java line 139: > 137: > 138: /** > 139: * Returns a Base64 decoded byte array of {@code content} Missing period. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359487443 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359520960 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359538618 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359525172 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359552326 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359591951 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359603695
