On Mon, 16 May 2022 21:08:48 GMT, Anthony Scarpino <ascarp...@openjdk.org>
wrote:
> There is too much grey area. It says the src buffer maybe modified, which one
> could interpret it cannot be a read-only, but that would still need
> clarification to explicitly say "no read only buffers". And other than these
> internal 'in-place' crypto reason, there is no API reason to not allow
> read-only buffers as input. I did think about closing the CSR as the text was
> already there about the src buffer, even thought it was using a different
> term. But I felt strongly enough that I wanted to prevent that confusion in
> the future.
I think it is good to make the clarification with a CSR.
As the spec says, "The inbound network buffer, {@code src}, may be modified",
applications cannot assume that the inbound network buffer cannot be modified
(read-only) any longer. It does not grant that an application will work with
read-only inbound buffers for another JSSE provider. As a result, an
application that want to support read-only buffers may also need to support
non-read-only buffers. As makes it more complicated in both application layers
and the JSSE implementation layer. It may be simple that applications and JSSE
implementation codes only need to handle non-read-only buffers.
Just my $0.02. I will let you and Brad for the final decision.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8462
