Hi,
In the message digest implementation, for example SHA256, in JDK, two bitwise
operations could be improved with equivalent arithmetic, and then the number
bitwise operations could be reduced accordingly. Specifically
"(x and y) xor ((complement x) and z)" could be replaced with the equivale
On Mon, 19 Sep 2022 17:01:40 GMT, Aleksey Shipilev wrote:
> The test helpers try to identify NSS version by parsing the relevant `.so`
> files (!) looking for "Version: ..." string. This fails at least on Ubuntu
> 22.04, where the NSS does not have any version-identifiable strings. In this
> c
On Mon, 19 Sep 2022 17:01:40 GMT, Aleksey Shipilev wrote:
> The test helpers try to identify NSS version by parsing the relevant `.so`
> files (!) looking for "Version: ..." string. This fails at least on Ubuntu
> 22.04, where the NSS does not have any version-identifiable strings. In this
> c
On Mon, 19 Sep 2022 18:50:46 GMT, Roger Riggs wrote:
> As mentioned earlier in the comments... This is a completely compatible
> change. Removing a field is well specified as a compatible change. From old
> version to new version the value in the stream is discarded. From a new
> version to th
On Mon, 19 Sep 2022 19:08:07 GMT, Mark Powers wrote:
> I ran the test in the reverse direction. No difference in behavior was
> observed.
Great, thanks for confirming.
-
PR: https://git.openjdk.org/jdk/pull/10206
On Mon, 19 Sep 2022 17:01:40 GMT, Aleksey Shipilev wrote:
> The test helpers try to identify NSS version by parsing the relevant `.so`
> files (!) looking for "Version: ..." string. This fails at least on Ubuntu
> 22.04, where the NSS does not have any version-identifiable strings. In this
> c
On Tue, 20 Sep 2022 17:47:03 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 updat
On Tue, 20 Sep 2022 17:53:27 GMT, Sean Mullan wrote:
> Now that this API has a section about signed JARs, I think it is very
> important to include the following sentences which are copied from `JarFile`:
>
> "Please note that the verification process does not include validating the
> signer's
> 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 w
On Tue, 20 Sep 2022 17:47:03 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 updat
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 JarIn
> 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 w
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 rea
> 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 w
On Tue, 20 Sep 2022 11:19:07 GMT, Claes Redestad wrote:
> [JDK-8285263](https://bugs.openjdk.org/browse/JDK-8285263) innocuously
> rewrote an anonymous class in `SecureClassLoader.getProtectionDomain` to a
> (capturing) lambda. Since this is called during early bootstrap this shows up
> as a r
On Tue, 20 Sep 2022 11:19:07 GMT, Claes Redestad wrote:
> [JDK-8285263](https://bugs.openjdk.org/browse/JDK-8285263) innocuously
> rewrote an anonymous class in `SecureClassLoader.getProtectionDomain` to a
> (capturing) lambda. Since this is called during early bootstrap this shows up
> as a r
On Mon, 19 Sep 2022 17:33:33 GMT, Valerie Peng wrote:
> Looks good.
Thank you! Any other reviews needed, or this one is enough?
-
PR: https://git.openjdk.org/jdk/pull/10346
On Tue, 20 Sep 2022 11:19:07 GMT, Claes Redestad wrote:
> [JDK-8285263](https://bugs.openjdk.org/browse/JDK-8285263) innocuously
> rewrote an anonymous class in `SecureClassLoader.getProtectionDomain` to a
> (capturing) lambda. Since this is called during early bootstrap this shows up
> as a r
[JDK-8285263](https://bugs.openjdk.org/browse/JDK-8285263) innocuously rewrote
an anonymous class in `SecureClassLoader.getProtectionDomain` to a (capturing)
lambda. Since this is called during early bootstrap this shows up as a
regression across the board on all our startup and footprint tests.
On Mon, 19 Sep 2022 20:30:48 GMT, Weijun Wang wrote:
> Does this mean that the "Verifying a JarInputStream" should also avoid
> mentioning "getManifest method returns the manifest"? I understand precisely
> it should be "getManifest method is able to return the manifest if you call
> it".
See
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 to
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
22 matches
Mail list logo
