On Mon, 9 May 2022 09:56:19 GMT, Volker Simonis wrote:
>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)`
>> to highlight that it might write more bytes than the returned number of
>> inflated bytes into the buffer `b`.
>>
>> The s
y construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails
> with zlib-chromi
On Wed, 30 Mar 2022 10:26:56 GMT, Lance Andersen wrote:
>>> Hello Volker, An additional thing that we might have to consider here is
>>> whether adding this javadoc change to `InflaterInputStream` is ever going
>>> to "show up" to end user applications. What I mean is, I think in many
>>>
On Mon, 2 May 2022 12:32:25 GMT, Volker Simonis wrote:
>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)`
>> to highlight that it might write more bytes than the returned number of
>> inflated bytes into the buffer `b`.
>>
>> The s
y construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails
> with zlib-chromi
On Wed, 13 Apr 2022 17:42:57 GMT, Volker Simonis wrote:
>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)`
>> to highlight that it might write more bytes than the returned number of
>> inflated bytes into the buffer `b`.
>>
>> The s
y construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails
> with zlib-chromi
On Sun, 3 Apr 2022 19:04:21 GMT, Alan Bateman wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Extended API-doc based on reviewer feedback
>
> A suggestion for the structure
On Tue, 12 Apr 2022 18:12:03 GMT, Lance Andersen wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adapted wording based on @AlanBateman's review, removed implementation
>> n
y construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails
> with zlib-chromi
y construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails
> with zlib-chromi
On Mon, 11 Apr 2022 16:04:48 GMT, Alan Bateman wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adapted wording and copyrights based on @jaikiran review
>
> src/java.ba
On Mon, 11 Apr 2022 16:07:15 GMT, Alan Bateman wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adapted wording and copyrights based on @jaikiran review
>
> src/java.ba
On Mon, 11 Apr 2022 16:05:33 GMT, Alan Bateman wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adapted wording and copyrights based on @jaikiran review
>
> src/java.ba
On Fri, 8 Apr 2022 13:21:06 GMT, Jaikiran Pai wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added API-refinement to GZIPInputStream::read()/ZipInputStream::read() and
>> an
y construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails
> with zlib-chromi
On Fri, 8 Apr 2022 13:11:23 GMT, Jaikiran Pai wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added API-refinement to GZIPInputStream::read()/ZipInputStream::read() and
>> an
On Tue, 29 Mar 2022 12:43:25 GMT, Volker Simonis wrote:
>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)`
>> to highlight that it might write more bytes than the returned number of
>> inflated bytes into the buffer `b`.
>>
>> The s
y construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails
> with zlib-chromi
On Tue, 29 Mar 2022 01:58:05 GMT, Jaikiran Pai wrote:
> Hello Volker, An additional thing that we might have to consider here is
> whether adding this javadoc change to `InflaterInputStream` is ever going to
> "show up" to end user applications. What I mean is, I think in many cases the
> end
On Mon, 28 Mar 2022 18:23:46 GMT, Lance Andersen wrote:
>> I think this require a bit of word smithing. If the return value is 'n' then
>> it should make it clear that the values in elements b[off + n] to b[off +
>> len - 1] are undefined, their values may or may have been changed by the
>>
y construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails
> with zlib-chromi
On Mon, Mar 28, 2022 at 7:33 PM Alan Bateman wrote:
>
> On 28/03/2022 11:02, Volker Simonis wrote:
> > :
> > As I wrote before, the extra data written into the output buffer isn't
> > sensitive because it can only originate from the history buffer (aka
> > &quo
On Mon, 28 Mar 2022 10:18:32 GMT, Lance Andersen wrote:
> Hi Volker,
>
> I believe your PR should point to the [JBS
> issue](https://bugs.openjdk.java.net/browse/JDK-8282648) in the title, which
> references the CSR and not the CSR directly in the title.
Sorry, you're right of course :)
y construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails
> with zlib-ch
On Mon, Mar 28, 2022 at 10:53 AM Alan Bateman wrote:
>
> On 22/03/2022 12:28, Volker Simonis wrote:
> > :
> > I don't really understand this concern? Do you mean what happens if
> > another thread is changing the content of the output buffer during an
> > inflat
Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to
highlight that it might write more bytes than the returned number of inflated
bytes into the buffer `b`.
The superclass `java.io.InputStream` specifies that `read(byte[] b, int off,
int len)` will leave the content
on relaxes the specification of read(..)
which would be hard to check :)
Thank you and best regards,
Volker
> Best
> Lance
>
>
> On Mar 4, 2022, at 5:04 AM, Volker Simonis wrote:
>
> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater
> functionality.
On Mon, Mar 21, 2022 at 8:19 PM Alan Bateman wrote:
>
Hi Alan,
Thanks for looking at this issue. Please find my answers to your
questions inline:
> On 04/03/2022 10:04, Volker Simonis wrote:
> > :
> >
> > 1. Relax the specification of `InflaterInputStream::read(..)` a
Ping...
On Thu, Mar 10, 2022 at 8:26 PM Lance Andersen
wrote:
> Hi Volker,
>
> Thank you for the reminder
>
> This is on my radar as well but have not had a chance spend any time on
> this as yet.
>
>
>
> On Mar 9, 2022, at 2:33 PM, Volker Simonis
> wrote:
&g
@Alan, @Lance,
Sorry for my obtrusiveness, but what's your opinion on this issue?
Thank you and best regards,
Volker
On Fri, Mar 4, 2022 at 11:04 AM Volker Simonis wrote:
>
> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater
> functionality. `Inflater::inf
On Wed, 11 Nov 2020 11:58:08 GMT, Lance Andersen wrote:
>> Hi,
>>
>> Please review the fix for JDK-8256018 which addresses the issue that the
>> update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use
>> Reference.reachabilityFence to ensure that direct byte buffer are kept
`java.util.zip.Inflater` is the Java wrapper class for zlib's inflater
functionality. `Inflater::inflate(byte[] output, int off, int len)`
currently calls zlib's native `inflate(..)` function and passes the
address of `output[off]` and `len` to it via JNI.
The specification of zlib's
On Wed, 16 Feb 2022 09:30:46 GMT, Volker Simonis wrote:
> Currently, `InflaterInputStream::read()` first does a native call to the
> underlying zlib `inflate()` function and only afterwards checks if the
> inflater requires input (i.e. `Inflater::needsInput()`) or has finished
&g
On Mon, 21 Feb 2022 18:05:08 GMT, Lance Andersen wrote:
>>> The change looks innocuous so it is probably OK. I would like to kick of
>>> our Mach5 runs to see if it shakes out any potential issues.
>>
>> @LanceAndersen , did you manage to get any Mach5 results? Did you find any
>> issues?
>
On Mon, 21 Feb 2022 18:05:08 GMT, Lance Andersen wrote:
> > > The change looks innocuous so it is probably OK. I would like to kick of
> > > our Mach5 runs to see if it shakes out any potential issues.
> >
> >
> > @LanceAndersen , did you manage to get any Mach5 results? Did you find any
> >
On Fri, 18 Feb 2022 08:46:51 GMT, Volker Simonis wrote:
> The change looks innocuous so it is probably OK. I would like to kick of our
> Mach5 runs to see if it shakes out any potential issues.
@LanceAndersen , did you manage to get any Mach5 results? Did you find any
On Thu, 17 Feb 2022 20:58:54 GMT, Lance Andersen wrote:
> The change looks innocuous so it is probably OK. I would like to kick of our
> Mach5 runs to see if it shakes out any potential issues.
>
Thanks Lance! Much appreciated.
> From reading the 3rd party problem reports, it appears that
On Thu, 17 Feb 2022 09:59:08 GMT, Alan Bateman wrote:
> This change is probably okay
Hi Alan,
thanks for looking at this change.
> but will require study to see if there are any side effects (sadly, this area
> has a history of side effects being reported months and years after a
>
On Thu, 17 Feb 2022 10:01:11 GMT, Claes Redestad wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changed hardcoded constant to JMH parmater and removed non-ASCII chars
>> fr
te some padding bytes
> at the beginning of the `data` array and overwrite the previously read data.
> This issue has been reported in Spring [1] and ASM [2] when using these
> libraries with Cloudflares zlib version (by setting `LD_LIBRARY_PATH`
> accordingly).
>
> [1] htt
On Thu, 17 Feb 2022 09:35:47 GMT, Christoph Langer wrote:
> Makes sense to me. Benchmark numbers look good.
Thanks Christoph!
-
PR: https://git.openjdk.java.net/jdk/pull/7492
Currently, `InflaterInputStream::read()` first does a native call to the
underlying zlib `inflate()` function and only afterwards checks if the inflater
requires input (i.e. `Inflater::needsInput()`) or has finished inflating
(`Inflater::finished()`). This leads to an unnecessary native call to
On Wed, 17 Nov 2021 18:48:14 GMT, Volker Simonis wrote:
> In JDK 9, function objects implemented as anonymous inner classes in
> java.util.regex.Pattern have been replaced by lambda functions (see
> [JDK-8151481](https://bugs.openjdk.java.net/browse/JDK-8151481)). This led to
> a
On Wed, 17 Nov 2021 18:48:14 GMT, Volker Simonis wrote:
> In JDK 9, function objects implemented as anonymous inner classes in
> java.util.regex.Pattern have been replaced by lambda functions (see
> [JDK-8151481](https://bugs.openjdk.java.net/browse/JDK-8151481)). This led to
> a
In JDK 9, function objects implemented as anonymous inner classes in
java.util.regex.Pattern have been replaced by lambda functions (see
[JDK-8151481](https://bugs.openjdk.java.net/browse/JDK-8151481)). This led to a
significant performance regression (up to ~8X) for patterns with negated
On Tue, 28 Sep 2021 10:01:43 GMT, Claes Redestad wrote:
>> Not too much work. I recently introduced platform-specific `matcher_*.hpp`
>> files, so since then adding a boolean constant is easy (no need to muck with
>> the .ad files).
>
> Does the changes in 9800a99 resolve your concerns?
In
On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote:
> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to
> work also for ASCII encoding, which makes for example the `UTF_8$Encoder`
> perform on par with (or outperform) similarly getting charset encoded bytes
> from
Thanks for the quick confirmation!
On Tue, Aug 3, 2021 at 4:41 PM Alan Bateman wrote:
>
> On 03/08/2021 15:36, Volker Simonis wrote:
> > Hi,
> >
> > I have a quick question on JDK-8198997 [1] (a follow-up of JDK-8194154
> > [2]) which introduced normalization for
Hi,
I have a quick question on JDK-8198997 [1] (a follow-up of JDK-8194154
[2]) which introduced normalization for the cached "user.dir" property
in order to avoid "inefficient, repeated normalization".
However, from what I can see, WinNTFileSystem.getUserPath(), the only
place where the cached
On Wed, 9 Jun 2021 08:53:40 GMT, Yi Yang wrote:
>> The JDK codebase re-created many variants of checkIndex(`grep -I -r
>> 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which
>> annotated with @IntrinsicCandidate and it only has a corresponding C1
>> intrinsic version.
On Wed, 9 Jun 2021 08:53:40 GMT, Yi Yang wrote:
>> The JDK codebase re-created many variants of checkIndex(`grep -I -r
>> 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which
>> annotated with @IntrinsicCandidate and it only has a corresponding C1
>> intrinsic version.
Hi Alan,
thanks for the quick response. Please find my answers inline
On Wed, Mar 3, 2021 at 1:38 PM Alan Bateman wrote:
>
> On 03/03/2021 10:43, Volker Simonis wrote:
> > :
> >
> > My question now is if this is an inherent property of the module
> > system or m
Hi,
I have a question about how changing the system class loader by
setting "java.system.class.loader" interacts with the module system. I
couldn't find a lot of information on this topic but if it has been
discussed before please point me to the corresponding place.
Traditionally, setting
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 genera
On Wed, 14 Oct 2020 16:31:32 GMT, Lance Andersen wrote:
> Mach5 run is clean :-)
Thanks a lot Lance.
Just waiting for the CSR to get approved now.
-
PR: https://git.openjdk.java.net/jdk/pull/520
-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]:
> https://bugs.openjdk.java.net/browse/
On Wed, 14 Oct 2020 10:48:55 GMT, Volker Simonis wrote:
>> test/jdk/java/util/zip/CopyZipFile.java line 104:
>>
>>> 102: // all these fields set to '-1'.
>>> 103: InputStream is = new FileInputStream(ZIP_FILE);
>>> 104:
On Tue, 13 Oct 2020 19:56:50 GMT, Lance Andersen wrote:
>> Volker Simonis has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental
>> views will show differences compared to the previous content of the PR.
>
>
On Tue, 13 Oct 2020 17:16:21 GMT, Lance Andersen wrote:
>> Volker Simonis has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase.
>
> test/jdk/java/util/z
On Tue, 13 Oct 2020 18:50:00 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 87:
>>
>>> 85: *
>>> 86: * The current time will be used if the entry has no set
>>> modification
>>> 87: * time.
>>
>> I'm happy with the wording.
-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]:
> https://bugs.openjdk.java.net/browse/
-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]:
> https://bugs.openjdk.java.net/browse/
On Mon, 21 Sep 2020 12:45:55 GMT, Jason Tatton
wrote:
>> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1
>> byte encoded Strings). It is provided for
>> x86 and ARM64. The implementation is greatly inspired by the indexOf(char)
>> intrinsic for StringUTF16. To
On Fri, 18 Sep 2020 11:56:09 GMT, Jason Tatton
wrote:
>> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1
>> byte encoded Strings). It is provided for
>> x86 and ARM64. The implementation is greatly inspired by the indexOf(char)
>> intrinsic for StringUTF16. To
On Fri, 18 Sep 2020 11:56:09 GMT, Jason Tatton
wrote:
>> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1
>> byte encoded Strings). It is provided for
>> x86 and ARM64. The implementation is greatly inspired by the indexOf(char)
>> intrinsic for StringUTF16. To
a broader discussion about its usefulness on the "discuss" list? Or is your
rejection definitive, no matter what the outcome of such a discussion will
be?
Thank you and best regards,
Volker
On Fri, Jul 24, 2020 at 10:16 PM Brian Goetz wrote:
>
>
> On 7/24/2020 7:48 AM, V
On Fri, Jul 24, 2020 at 2:15 PM Alan Bateman wrote:
>
>
> On 24/07/2020 12:48, Volker Simonis wrote:
> > :
> >
> > I can't see much complexity here. If you look at the change you'll see
> > that it's rather trivial. All it does is substituting some direc
On Thu, Jul 23, 2020 at 8:48 PM Alan Bateman wrote:
>
> On 23/07/2020 18:18, Volker Simonis wrote:
> > Hi,
> >
Hi Alan,
thanks for promptly looking into my proposal. Please find my answers inline:
> > can I please get some reviews for the following small enhancement
not all of the above, including a JEP
> needs to be further flushed out.
>
I think this topic is by far not that complex to justify a JEP and I
think I've answered all your questions and concerns. However, if you
still insist on getting these answers in a JEP I'll be happy to do so
:)
Thanks
Hi,
can I please get some reviews for the following small enhancement
which will allow you to configure different zlib implementations at VM
start-up and get up to 100% better throughput for compression and
about 50% better throughput for decompression (depending on the
selected zlib
patch now that Claes’s changes are back as I think
> that would make it easier to review
>
> Thank you!
>
> On May 8, 2020, at 11:36 AM, Volker Simonis
> wrote:
>
> Hi,
>
> can I please have a review for the following small enhancement which
> improves the speed of r
Hi,
can I please have a review for the following small enhancement which
improves the speed of reading from ZipFile.getInputStream() by ~5%:
http://cr.openjdk.java.net/~simonis/webrevs/2020/8244659/
https://bugs.openjdk.java.net/browse/JDK-8244659
ZipFile.getInputStream() tries to find a good
Hi,
can I please get a review for the following trivial change which fixes
the Amazon copyright in several test files:
http://cr.openjdk.java.net/~simonis/webrevs/2020/8244094/
https://bugs.openjdk.java.net/browse/JDK-8244094
Notice that the new version intentionally contains no copyright year
On Sun, Apr 26, 2020 at 11:34 PM Claes Redestad
wrote:
>
> Hi again,
>
> On 2020-04-24 21:22, Claes Redestad wrote:
> >> It seems that 'getEntryHitUncached' is getting slightly slower with
> >> your change while all the other variants get significantly faster. I
> >> don't think that's a problem,
On Thu, Apr 23, 2020 at 2:35 PM Claes Redestad
wrote:
>
> Hi,
>
> current implementation of ZipFile.getEntryPos takes the encoded byte[]
> of the String we're looking up. Which means when looking up entries
> across multiple jar files, we allocate the byte[] over and over for each
> jar file
On Wed, Apr 22, 2020 at 10:45 PM Claes Redestad
wrote:
>
>
>
> On 2020-04-22 22:08, Volker Simonis wrote:
> > http://cr.openjdk.java.net/~simonis/webrevs/2020/8242848.02/
> >
> > Notice that this new version only changes the microbenchmark, all the
nt
>
> Le jeu. 23 avr. 2020 à 12:19, Volker Simonis a
> écrit :
>>
>> On Thu, Apr 23, 2020 at 10:56 AM Laurent Bourgès
>> wrote:
>> >
>> > Hi Volker,
>> >
>> > Could you give some benchmark results in the jbs bug to have a
On Thu, Apr 23, 2020 at 1:22 PM Lance Andersen
wrote:
> Hi Volker
>
> On Apr 22, 2020, at 4:08 PM, Volker Simonis
> wrote:
>
> On Tue, Apr 21, 2020 at 5:23 PM Lance Andersen
> wrote:
>
>
> Hi Volker,
>
> I think overall this looks OK. I went through th
-Original Message-----
> > From: core-libs-dev On Behalf
> > Of Volker Simonis
> > Sent: Mittwoch, 22. April 2020 22:09
> > To: Lance Andersen
> > Cc: Java Core Libs ; Vyom Tewari
> >
> > Subject: Re: RFR(S): 8242848: Improve performance of
>
il/zip/DeflateIn_InflateOut.java in lines 48/49 and 59/60
>> does not match the other if/else blocks in the file. You should probably
>> have the else on the line of the closing bracket before...
>>
>> Thanks
>> Christoph
>>
>>
>> > -Original Messa
mprove the performance.
>
> Best
> Lance
>
> On Apr 17, 2020, at 6:49 AM, Volker Simonis wrote:
>
> Thanks everybody for looking at this change!
>
> Please find an updated webrev (with a new test and micro-benchmark)
> and my answers to your comments below:
>
>
nobody else complains, I'll probably leave it as is :)
> Nice test :)
Thank you :)
Volker
>
> Thomas
>
>
> On Fri, Apr 17, 2020 at 12:50 PM Volker Simonis
> wrote:
>>
>> Thanks everybody for looking at this change!
>>
>> Please find an updated web
va.net/jdk/jdk/file/f499459eda7a/test/jdk/java/text/Format/DateFormat/Bug8235699.java
Best regards,
Volker
> Thanks,
> Vyom
>
> On Fri, Apr 17, 2020 at 4:23 PM Volker Simonis
> wrote:
>>
>> Thanks everybody for looking at this change!
>>
>> Please find an up
is an internal, implementation specific setting
which has never been exposed or documented before so I don't see why
we should document it now. But let's discuss this separately in the
corresponding JBS issue (see below).
On Thu, Apr 16, 2020 at 1:18 PM Claes Redestad
wrote:
>
> Hi
Hi,
can I please have a review for the following simple performance enhancement:
http://cr.openjdk.java.net/~simonis/webrevs/2020/8242848/
https://bugs.openjdk.java.net/browse/JDK-8242864
InflaterOutputStream has an internal buffer which is used for the
inflated data. This buffer can be
Task.java as well
>
> Best
> Lance
>
> On Mar 3, 2020, at 11:27 AM, Alan Bateman wrote:
>
> On 03/03/2020 11:01, Volker Simonis wrote:
>
> Hi,
>
> can I please get a review for the following small fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2020/824
On Tue, Mar 3, 2020 at 5:27 PM Alan Bateman wrote:
>
> On 03/03/2020 11:01, Volker Simonis wrote:
> > Hi,
> >
> > can I please get a review for the following small fix:
> >
> > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/
> > https:
gt;
You can't know it be fore you are doing it :)
> On Tue, Mar 3, 2020 at 3:02 AM Volker Simonis
> wrote:
>>
>> Hi,
>>
>> can I please get a review for the following small fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/
>> https://b
Hi,
can I please get a review for the following small fix:
http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/
https://bugs.openjdk.java.net/browse/JDK-8240333
The "jmod" tool needs to update .jar files as well as .jmod files when
adding hashes to the module-info file. This is handled in
On Tue, Mar 3, 2020 at 10:26 AM Andrew Haley wrote:
>
> On 3/2/20 10:46 PM, Volker Simonis wrote:
>
> > As lead of the 8 and 11 update projects you probably know best, if this fix
> > will eventually be considered for backporting and choose your means wisely
> >
Andrew Haley schrieb am Mo., 2. März 2020, 13:00:
> On 11/19/18 8:39 PM, Kim Barrett wrote:
> > I don't see any benefit to making the first C++ code change that uses
> > a new feature also incorporate the needed build system changes.
> > Indeed, how does one develop that feature usage unless one
Hi,
can I please have a review for this small test fix:
http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235/
https://bugs.openjdk.java.net/browse/JDK-8240235
JarUtils.updateJar() and JarUtils.updateJarFile() update jar files by
reading JarEntry-s from a source jar file and writing these
On Fri, Feb 28, 2020 at 6:11 PM Alan Bateman wrote:
>
>
>
> On 28/02/2020 15:39, Martin Buchholz wrote:
> > LGTM.
> > We're all resisting the urge to modernize this test.
> >
> yeah, that is a very old test. The change looks good to me too.
>
Thanks, Alan!
> -Alan
On Fri, Feb 28, 2020 at 4:40 PM Martin Buchholz wrote:
>
> LGTM.
Thanks, for your review Martin.
> We're all resisting the urge to modernize this test.
I have some more zip-related fixes in the queue :)
>
> On Fri, Feb 28, 2020 at 5:17 AM Volker Simonis
> wrote:
>>
&
Hi,
can I please get a review for this trivial test fix:
http://cr.openjdk.java.net/~simonis/webrevs/2020/8240226/
https://bugs.openjdk.java.net/browse/JDK-8240226
The SkipBytes() subtest in DeflateIn_InflateOut.java executes several
steps and for each step it deflates an array of 1024*1024
I think you should also look at
https://bugs.openjdk.java.net/browse/JDK-8238534 for which a fix is
currently discussed on build-dev (
https://mail.openjdk.java.net/pipermail/build-dev/2020-February/026703.html
).
The sheer number of different mailing list has always been a big problem
for
t; > >> year is
> > >> needed)
> > >> Thanks, Roger
> > >>On 1/2/20 4:18 PM, Verghese, Clive wrote:
> > >> > Hi Alan,
> > >> >
> > >>
Hi,
is there any reason why the bundled zlib is patched to make zlib's
"uLong" type a 32-bit int on 64-bit platforms [1]? This change to the
original zlib is there since the very first drop of OpenJDK 6 [2] (which
still had version 1.1.3 of zlib). Maybe it was required at that time
when it was
On 02.01.20 18:39, Alan Bateman wrote:
> On 02/01/2020 13:26, Volker Simonis wrote:
>> :
>> http://cr.openjdk.java.net/~simonis/webrevs/2020/8235699.02/
>>
>> Ready to push?
>>
> You shouldn't need to use core reflection here. Instead you can create
> t
1 - 100 of 394 matches
Mail list logo
