On Thu, 8 May 2025 04:46:31 GMT, Anthony Scarpino <[email protected]> wrote:
>> src/java.base/share/classes/java/security/PEMDecoder.java line 228:
>>
>>> 226: * <p>This method will read the {@code InputStream} until PEM data
>>> is
>>> 227: * found or until the end of the stream. Non-PEM data in the
>>> 228: * {@code InputStream} before the PEM header will be ignored by
>>> the decoder.
>>
>> This is not precise because you might put the leading data into a
>> `PEMRecord`.
>>
>> Also, I think it's very important to point out the pointer position of the
>> input stream after this method is successfully called. Otherwise, the method
>> cannot be reliably used in extracting multiple PEMs from a single stream.
>>
>> Also, I'm not exactly sure what happens when there is nothing more to read.
>
> There is an inconsistency with PEMRecord here. These methods should not
> allow leadingData if it is not available elsewhere. I will redo that.
> leadingData can be reserved for the decode methods that take a class.
>
> I tried not to mention the pointer position. My opinion is these methods
> should not have to describe the InputStream functionality. I already state
> it returns a value after it finds PEM and I think one can figure this out.
See
https://github.com/openjdk/jdk/blob/002679ac9fe4de8150b7dd4c9aeb44eeef1257d6/src/java.base/share/classes/java/security/cert/CertificateFactory.java#L338-L347
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080497787
