On Tue, 20 Sep 2022 17:37:50 GMT, Alan Bateman wrote:
>>> > OK, will make another pass at this today
>>>
>>> I looked at the latest draft
>>> ([2bafc00](https://github.com/openjdk/jdk/commit/2bafc00cc462b7af3f724371ac1bef5fd99c989c)).
>>> I think it would help if the section "Verifying a
On Tue, 20 Sep 2022 10:49:59 GMT, Lance Andersen wrote:
>>> OK, will make another pass at this today
>>
>> I looked at the latest draft (2bafc00c). I think it would help if the
>> section "Verifying a JarInputStream" were renamed to "Signed JAR files".
>> The link to getManifest makes the
On Tue, 20 Sep 2022 06:56:49 GMT, Alan Bateman wrote:
>>> I realise you've had a few iterations with Max on this section but I'm
>>> concerned that the text is telling the reader that they should use the
>>> 2-arg constructor to verify the signatures when a JAR is signed. The
>>> default is
On Mon, 19 Sep 2022 10:21:30 GMT, Lance Andersen wrote:
> OK, will make another pass at this today
I looked at the latest draft (2bafc00c). I think it would help if the section
"Verifying a JarInputStream" were renamed to "Signed JAR files". The link to
getManifest makes the reader wonder if
On Mon, 19 Sep 2022 06:45:13 GMT, Alan Bateman wrote:
> I realise you've had a few iterations with Max on this section but I'm
> concerned that the text is telling the reader that they should use the 2-arg
> constructor to verify the signatures when a JAR is signed. The default is to
> verify
On Sun, 18 Sep 2022 20:43:25 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this
> Please review this PR which updates the JarInputStream class description to
> clarify when the Manifest is accessible via JarInputStream::getManifest and
> JarInputStream::get[Jar]Entry.
>
> It is worth noting that with this update, we are finally documenting
> behavior that dates back to
