RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v6]

Sean Mullan mullan at openjdk.org
Tue Oct 14 18:22:39 UTC 2025


On Tue, 14 Oct 2025 03:55:54 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates
>
> src/java.base/share/classes/java/security/PEM.java line 68:
> 
>> 66:  * metadata that accompanies the PEM data. This value was not defensively
>> 67:  * copied by the constructor, and the {@link #leadingData()} method does not
>> 68:  * return a clone.
> 
> I see the Javadoc already notes that leadingData isn’t defensively copied or cloned. Given that PEM is a record (and callers might assume immutability), should we clarify ownership semantics a bit more — e.g., that the caller must not modify the array after passing it in?

The javadoc should clearly describe the mutability aspects, but we can't control what the caller does after that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430031746


More information about the security-dev mailing list