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 configur
.
I don't think so. This 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
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
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 update
u for helping improve 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 bel
/util/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
>>
>>
>> > -Orig
> -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
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
Laurent
>
> 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 an
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
> > o
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 searc
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,
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 a
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 s
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 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 implementatio
more supportive to such an
approach compared to this change?
> I believe to move forward some, if 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
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
>
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 substitutin
a JEP for this enhancement and have
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 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 inco
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 inco
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 inco
uild-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-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.n
uild-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-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.n
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. Wha
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 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.
>
>
uild-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-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.n
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
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
Hi Michael,
have you had a look at the recently added enhancements for zipfs:
8213031: (zipfs) Add support for POSIX file permissions
https://bugs.openjdk.java.net/browse/JDK-8213031
The corresponding CSR
8213082: (zipfs) Add support for POSIX file permissions
https://bugs.openjdk.java.net/brow
On 13.11.19 17:26, Langer, Christoph wrote:
Hi Volker,
good catch in ZipFileSystem 😊 The fix is the right thing to do.
Hi Christoph,
thanks for looking at my fix. I've prepared a new webrev at:
http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/
Please find my further comments inl
On 14.11.19 16:27, Lance Andersen wrote:
Hi Volker,
On Nov 14, 2019, at 8:53 AM, Volker Simonis <mailto:simon...@amazon.com>> wrote:
On 13.11.19 18:54, Lance Andersen wrote:
Hi Volker,
Thank you for doing this.
As Christoph mentioned, you can just do Path.of() and create the
fi
On 13.11.19 18:54, Lance Andersen wrote:
Hi Volker,
Thank you for doing this.
As Christoph mentioned, you can just do Path.of() and create the file
in the work directory for the test.
Done.
If possible, I would use TestNG as that is consistent with the vast
majority of the tests.
I
On 14.11.19 17:38, Lance Andersen wrote:
On Nov 14, 2019, at 11:27 AM, Volker Simonis <mailto:simon...@amazon.com>> wrote:
On 14.11.19 16:27, Lance Andersen wrote:
Hi Volker,
On Nov 14, 2019, at 8:53 AM, Volker Simonis <mailto:simon...@amazon.com><mailto:simon...@amazon
gnize this and adapt the test in the same change?
OK, changed it to a RuntimeException now.
Here's the new webrev:
http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v3
Best regards
Christoph
*From:* Lance Andersen
*Sent:* Donnerstag, 14. November 2019 17:38
*To:* Volker Si
On 14.11.19 21:20, Lance Andersen wrote:
Hi Volker,
On Nov 14, 2019, at 12:05 PM, Volker Simonis <mailto:simon...@amazon.com>> wrote:
On 14.11.19 17:38, Lance Andersen wrote:
On Nov 14, 2019, at 11:27 AM, Volker Simonis <mailto:simon...@amazon.com> <mailto:simon...@amazon.co
riginal Message-
From: Volker Simonis
Sent: Freitag, 15. November 2019 12:30
To: Langer, Christoph ; Volker Simonis
Cc: core-libs-dev@openjdk.java.net; Lance Andersen
Subject: Re: RFR(XS): 8234011: (zipfs) Memory leak in
ZipFileSystem.releaseDeflater()
On 14.11.19 18:24, Langer, Christoph wro
Hi Clive,
nice catch :)
I think it would be better though to only iterate up to MAX_FIELD and
print "field[MAX_FIELD + i]", otherwise you may miss to print valid
fields. The reason is that with your current solution "isSet()" will
now be called not only for "stamp" fields, but also for "real" fie
omments.
> http://cr.openjdk.java.net/~phh/8235699/webrev.01/
>
> Regards,
> Clive Verghese
>
> On 12/13/19, 8:09 AM, "Volker Simonis" wrote:
>
> Hi Clive,
>
> nice catch :)
>
> I think it would be better though to only iterate up to MAX_FIELD and
>
On 31.12.19 18:06, Alan Bateman wrote:
> On 31/12/2019 16:54, Verghese, Clive wrote:
>> Hi Volker,
>>
>> Thank you for reviewing the changes and approving.
>>
> Do you know if there is any test coverage for this method? The builder
> is package-private and I think your original mail said that it wa
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
> th
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 sti
he
> > >> year is
> > >> needed)
> > >> Thanks, Roger
> > >>On 1/2/20 4:18 PM, Verghese, Clive wrote:
> > >> > Hi Alan,
> > >> >
> > >&g
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 extern
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 byte
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:
>&
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
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 exa
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
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
> >
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 t
>
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/
>>
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:
odTask.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/202
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 "java.
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
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,
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 a
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
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
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 pri
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
chara
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
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 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
still write 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).
>
&g
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
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
> change).
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 the
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 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 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 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
`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 `inflate(..)`
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 kept
@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. `Inf
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
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
deas? In fact my suggestion 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
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 b
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
> > i
point of view it is easy to artificially 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) "uninte
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 :)
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
> > &q
point of view it is easy to artificially 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) "unint
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
>> in
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
point of view it is easy to artificially 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) "unint
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
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
point of view it is easy to artificially 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) "unint
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
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 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: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
1 - 100 of 408 matches
Mail list logo
