On Wed, 7 Oct 2020 19:42:11 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java line 664:
>>
>>> 662: * engineUpdate() and engineDoFinal().
>>> 663: */
>>> 664: private int bufferCrypt(ByteBuffer input, ByteBuffer output,
>>
>> It looks l
On Wed, 7 Oct 2020 22:08:19 GMT, Hai-May Chao wrote:
>> Default algorithms are bumped to be based on PBES2 with AES-256 and SHA-256.
>> Please also review the CSR at
>> https://bugs.openjdk.java.net/browse/JDK-8228481.
>
> Looks good. Only minor comments.
CSR looks good. In "Sepcification" sect
On Thu, 8 Oct 2020 03:21:46 GMT, Anthony Scarpino wrote:
>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Xuelei comments
src/java.base/share/classes/com/sun/crypto/pr
On Wed, 7 Oct 2020 16:29:32 GMT, Xue-Lei Andrew Fan wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Xuelei comments
>
> src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java line 947:
>
>> 945:
On Wed, 7 Oct 2020 16:17:38 GMT, Xue-Lei Andrew Fan wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Xuelei comments
>
> src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java line 664:
>
>> 662:
On Wed, 7 Oct 2020 22:38:21 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Xuelei comments
>
> src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java line 939:
>
>> 937:
On Wed, 7 Oct 2020 21:40:43 GMT, Brent Christian wrote:
>> I decided to slightly change the way this large manifest file was being
>> created. I borrowed the idea from
>> `Zip64SizeTest`[1] to create the file and set its length to a large value. I
>> hope that is OK. If not, let me know, I
>> w
> 8253821: Improve ByteBuffer performance with GCM
Anthony Scarpino has updated the pull request incrementally with one additional
commit since the last revision:
Xuelei comments
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/411/files
- new: https://git.openjdk.java
On Wed, 7 Oct 2020 21:40:57 GMT, Brent Christian wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Second round of review comments addressed
>
> Marked as reviewed by bchristi (Reviewer).
Hello Lance, does the lates
On Thu, 1 Oct 2020 14:39:50 GMT, Jaikiran Pai wrote:
>> test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 78:
>>
>>> 76: bw.write("OOM-Test: ");
>>> 77: for (long i = 0; i < 2147483648L; i++) {
>>> 78: bw.write("a");
>>
>> As you probably noti
On Thu, 1 Oct 2020 14:42:21 GMT, Jaikiran Pai wrote:
>> Can I please get a review and a sponsor for a fix for
>> https://bugs.openjdk.java.net/browse/JDK-8242882?
>>
>> As noted in that JBS issue, if the size of the Manifest entry in the jar
>> happens to be very large (such that it exceeds
>>
On Wed, 7 Oct 2020 22:20:07 GMT, Hai-May Chao wrote:
>> Looks good. Only minor comments.
>
> CSR looks good. In "Sepcification" section: a typo in 'Thr iteration counts
> used by'. At the end, it describes the new
> system property will override the security properties and use the older and
> w
On Thu, 1 Oct 2020 20:02:34 GMT, Weijun Wang wrote:
> Default algorithms are bumped to be based on PBES2 with AES-256 and SHA-256.
> Please also review the CSR at
> https://bugs.openjdk.java.net/browse/JDK-8228481.
Looks good. Only minor comments.
src/java.base/share/classes/sun/security/pkcs1
On Wed, 7 Oct 2020 22:06:28 GMT, Hai-May Chao wrote:
>> Default algorithms are bumped to be based on PBES2 with AES-256 and SHA-256.
>> Please also review the CSR at
>> https://bugs.openjdk.java.net/browse/JDK-8228481.
>
> test/jdk/sun/security/mscapi/VeryLongAlias.java line 48:
>
>> 46:
>> 47:
On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore
wrote:
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API
> in 3 main ways:
> * first, by
On Tue, 29 Sep 2020 20:22:55 GMT, Anthony Scarpino
wrote:
> 8253821: Improve ByteBuffer performance with GCM
I will take a look as well.
-
PR: https://git.openjdk.java.net/jdk/pull/411
This patch contains the changes associated with the third incubation round of
the foreign memory access API incubation
(see JEP 393 [1]). This iteration focus on improving the usability of the API
in 3 main ways:
* first, by providing a way to obtain truly *shared* segments, which can be
access
On Tue, 29 Sep 2020 20:22:55 GMT, Anthony Scarpino
wrote:
> 8253821: Improve ByteBuffer performance with GCM
Impressive update and performance improvement! I have no major concerns, all
comments are just about trivial details
like indents.
src/java.base/share/classes/com/sun/crypto/provider/
On Wed, 7 Oct 2020 16:43:53 GMT, Volker Simonis wrote:
>> Alan makes a good point. Perhaps we keep things simple and focus solely on
>> tweaking the description of the change in
>> behavior which is described in your last paragraph
>
> I totally agree. What about using just the last sentence (a
On Wed, 7 Oct 2020 16:09:47 GMT, Lance Andersen wrote:
>> ### Summary
>>
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
>> which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>>
>> In general it is not safe to directly write a
On Wed, 7 Oct 2020 15:34:32 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 97:
>>
>>> 95: * and re-compute its value automatically after the associted data
>>> has been
>>> 96: * completely deflated.
>>> 97: *
>>
>> We probably
On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis wrote:
> ### Summary
>
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
> which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
>
> In general it is not safe to directly write a ZipEntr
On Wed, 7 Oct 2020 15:10:06 GMT, Alan Bateman wrote:
>> ### Summary
>>
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
>> which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>>
>> In general it is not safe to directly write a Z
On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis wrote:
> ### Summary
>
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
> which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
>
> In general it is not safe to directly write a ZipEntr
On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis wrote:
> ### Summary
>
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
> which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
>
> In general it is not safe to directly write a ZipEntr
On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis wrote:
> ### Summary
>
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
> which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
>
> In general it is not safe to directly write a ZipEntr
26 matches
Mail list logo
