On Sun, 12 May 2024 14:37:23 GMT, Chen Liang wrote:
> I believe this field only captures the 2 bytes at higher indices of External
> File Attribute; it's not the complete 4-byte external file attributes and
> this value is not captured unless "Version made by" field's larger index byte
> (byte
x27;, 'extra.attr' after
> these updates, and found nothing related to zip/jar. The `zip` and `jar`
> tests run clean:
>
>
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"
Eirik Bjørsnøs has updated the pull req
On Thu, 9 May 2024 12:00:13 GMT, Jaikiran Pai wrote:
> Hello Eirik, it will be better to merge with the latest master branch and run
> the tier tests before integrating.
Life happened, but I have now merged with the latest master and GHA runs green.
Did you want to run additional testing befor
Hi!
The java.util.zip.ZipError class seems unused in OpenJDK. I assume this is
legacy from the native ZIP implementation in Java 8.
This exception class extends InternalError and seems to have been added in
Java 6 to help compatibility with existing code catching InternalError
(JDK-4615343)
This
On Tue, 2 Jul 2024 12:51:26 GMT, Jaikiran Pai wrote:
> Can you issue a `/integrate delegate` command on this PR so that it then
> allows me to do the actual integration along with the Oracle side of changes?
Done. And big thanks for your help getting this long-lasting change across the
finish
On Mon, 4 Dec 2023 15:34:34 GMT, Eirik Bjørsnøs wrote:
> Please consider this PR which suggests we rename `ZipEntry.extraAttributes`
> to `ZipEntry.externalFileAttributes`.
>
> This field was introduced in
> [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), original
On Thu, 6 Jun 2024 17:03:57 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
>>
On Thu, 6 Jun 2024 17:03:57 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
>>
On Mon, 15 Jul 2024 10:01:47 GMT, Jaikiran Pai wrote:
>> Archie Cobbs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 12 commits:
>>
>> - Bump @since from 23 to 24.
>> - Merge branch 'master' into JDK-8322256
>> - Relabel "trai
via 8145260 and 8037394 for JDK 9
>
> The test should also be re-written at this point
>
> Jai or I can make a pass to see if there are any external usages via a
> corpus search but I tend to doubt it
>
> On Jun 30, 2024, at 3:20 AM, Eirik Bjørsnøs wrote:
>
> Hi!
>
On Fri, 19 Jul 2024 23:16:07 GMT, Archie Cobbs wrote:
>> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 143:
>>
>>> 141: * @param allowConcatenation true to allow multiple concatenated
>>> compressed data streams,
>>> 142: * or false to e
Please review this test-only, cleanup PR which proposes that we retire the
`jdk/java/util/zip/TestZipError.java` test.
The test has fallen out of sync with its original and stated purpose described
by its name, `@summary` tag and code comments. The error condition actually
being exercised has e
Please review this PR which suggests to deprecate the unused class
`java.util.zip.ZipError` for removal.
The class has been unsed by OpenJDK since the ZIP API was rewritten from
native to Java in JDK 9.
I opted to not explain the reason for the deprecation in detail, but instead
simply point
On Fri, 23 Aug 2024 19:13:23 GMT, Lance Andersen wrote:
> So would be good to also alert those projects if possible
I guess the deprecation warning itself is the "official" channel for
communicating this type of information. But I agree it doesn't hurt to alert at
least some of the larger proj
Please review this refactoring PR which moves the `ZipEntry.flags` field to
`ZipOutputStream.XEntry`.
Moving this field will save four bytes from the `ZipEntry` object size and also
saves an unneccessary read in `ZipFile.getZipEntry`.
Testing:
This PR is a refactoring of existing code and does
On Sat, 24 Aug 2024 10:49:56 GMT, Eirik Bjørsnøs wrote:
> Please review this refactoring PR which moves the `ZipEntry.flags` field to
> `ZipOutputStream.XEntry`.
>
> Moving this field will save four bytes from the `ZipEntry` object size and
> also saves an unnec
/jdk/java/util/jar"
>
>
> Performance:
>
> The JMH benchmark `java.util.zip.ZipFileGetEntry.getEntryHit` show a small
> but consistent improvement (2-3%).
Eirik Bjørsnøs has updated the pull request incrementally with one additional
commit since the last revision:
Revert "Rename XEn
; section there once we reach a concensus on the deprecation note in this PR.
>
> This deprecation was initially suggested here:
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html
Eirik Bjørsnøs has updated the pull request incrementally with one additional
commit si
On Tue, 27 Aug 2024 15:51:24 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which suggests to deprecate the unused class
>> `java.util.zip.ZipError` for removal.
>>
>> The class has been unsed by OpenJDK since the ZIP API was rewritten from
>> native to Ja
On Tue, 27 Aug 2024 17:24:42 GMT, Lance Andersen wrote:
> The javadoc should be focused on the current JDK release, not the prior
> history of this Class
Makes sense, let's focus on the current release.
> ```
> * @deprecated ZipError is deprecated and subject to removal in a
> * future rele
On Tue, 27 Aug 2024 20:37:12 GMT, Lance Andersen wrote:
> Other options could be:
>
> _ZipError is obsolete and is no longer used. ZipException should be used
> instead_
This looks good to me! I've pushed this with a an empty line above to visually
separate the class description from the java
; section there once we reach a concensus on the deprecation note in this PR.
>
> This deprecation was initially suggested here:
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html
Eirik Bjørsnøs has updated the pull request with a new target base due to a
merge or a
Please review this test-only PR which addresses several issues with the
`test/jdk/java/util/zip/Available.java` test:
* The test is converted to JUnit 5
* The test now creates its own test vector programmatically instead of relying
on a binary `input.jar` test vector
* Coverage is added for ca
On Sun, 25 Aug 2024 13:36:18 GMT, Lance Andersen wrote:
>> I think linking to the CSR would be fine, but there is no prerequisite for
>> API specs to link to CSRs. Need @jddarcy to double check here. I was
>> emulating `Thread.stop`:
>> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9
On Wed, 21 Aug 2024 09:59:38 GMT, Eirik Bjørsnøs wrote:
> Please review this test-only, cleanup PR which proposes that we retire the
> `jdk/java/util/zip/TestZipError.java` test.
>
> The test has fallen out of sync with its original and stated purpose
> described by its name,
On Wed, 28 Aug 2024 19:56:04 GMT, Lance Andersen wrote:
>> Sounds good. How would you like to do that?
>>
>> E.g. we could just remove the words "In particular, some GZIP compression
>> tools function by partitioning the input, compressing each partition
>> separately, and then concatenating t
On Wed, 28 Aug 2024 21:56:50 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
>
On Wed, 28 Aug 2024 21:56:50 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
>
On Wed, 28 Aug 2024 21:56:50 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
>
ed, but long-standing behavior of
> `ZipFileInputStream.available()` (The InputStream returned for `STORED`
> entries)
>
> Additionally, the test is split into multiple methods, adding javadoc
> comments for each of them.
Eirik Bjørsnøs has updated the pull request incremen
On Thu, 29 Aug 2024 16:21:36 GMT, Lance Andersen wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Collapse the ZipFile-related tests into a single, parameterized method
>
> test/jd
ed, but long-standing behavior of
> `ZipFileInputStream.available()` (The InputStream returned for `STORED`
> entries)
>
> Additionally, the test is split into multiple methods, adding javadoc
> comments for each of them.
Eirik Bjørsnøs has updated the pull request incremen
On Thu, 29 Aug 2024 16:50:56 GMT, Eirik Bjørsnøs wrote:
>> Please review this test-only PR which addresses several issues with the
>> `test/jdk/java/util/zip/Available.java` test:
>>
>> * The test is converted to JUnit 5
>> * The test now creates its own test vect
On Wed, 28 Aug 2024 11:12:42 GMT, Eirik Bjørsnøs wrote:
> Please review this test-only PR which addresses several issues with the
> `test/jdk/java/util/zip/Available.java` test:
>
> * The test is converted to JUnit 5
> * The test now creates its own test vector programmatic
On Fri, 30 Aug 2024 07:27:11 GMT, Eirik Bjørsnøs wrote:
> Please review this PR with picks up on the excellent work done by
> @archiecobbs in #18385
>
> The proposed changes aim to solve two issues with the current
> `java.util.zip.GZIPInputStream`:
>
> * The
Please review this PR with picks up on the excellent work done by @archiecobbs
in #18385
The proposed changes aim to solve two issues with the current
`java.util.zip.GZIPInputStream`:
* The class parses multiple concatenated GZIP files as a single stream. This
behavior is not documented in th
.
>
> Testing:
>
> * A new test `GZIPInputStreamConcat` verifies the behaviors being specified
> in this PR
> * A new test `GZIPInputStreamGzipCommand` verifies decompression of various
> GZIP files created using the `gzip` command.
Eirik Bjørsnøs has updated the pull request in
Hi,
ZipFile.isSignatureRelated currently returns true for paths such as the
following:
META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA
While this path does start with "META-INF/" and ends with ".DSA", the file
does not live in the META-INF/ directory _directly_,
>
> ZipFile.isSignatureRelated currently returns true for paths such as the
> following:
>
>
> META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA
>
I found a couple more call sites of SignatureFileVerifier.isBlockOrSF which
incorrectly treat [SF,DSA,RSA,EC] files as
Hi,
A common use case for java.util.zip in build tools involves copying
entries from a ZipFile or ZipInputStream to a ZipOutputStream without
actually modifying the data.
Example use cases include minification (make a JAR with only the
reachable classes) and merging (combine several JAR files int
Hi,
This PR updates the test TestTooManyEntries to not create gigabytes of
ZIP files, allowing the test to run fast and non-manual:
https://github.com/openjdk/jdk/pull/12231
May I please get some help with filing a JBS for this PR?
Thanks,
Eirik.
Hi,
ZipFile.Source.readFullyAt caps its calls to RandomAccessFile.readFully to
a maximum of 8192 bytes per call, like this:
int N = len;
> while (N > 0) {
> int n = Math.min(BUF_SIZE, N);
> zfile.readFully(buf, off, n);
> off += n;
> N -= n;
> }
I'm observing a ~10% speedup of t
Hi,
Please review the following PR which suggests updating the field access
methods in ZipUtils to use the VarHandle API when reading multibyte values
from byte arrays:
https://github.com/openjdk/jdk/pull/12273
Thanks,
Eirik.
>
> Please review the following PR which suggests updating the field access
> methods in ZipUtils to use the VarHandle API
> https://github.com/openjdk/jdk/pull/12273
>
Never mind, Claes pointed out that VarHandles may take some time to warp up
and we did indeed measure a regression for cold-start
On Sat, Jan 28, 2023 at 4:47 PM Alan Bateman
wrote:
> The intention of the test was exercise a multi-GB CEN. So I think it
>
would be great if it could be re-written as an automatic test but I
> think it should be a real ZIP file, make use of sparse files might help.
>
Alan,
Yes, this change do
On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen
wrote:
> I think it is fine to move the validation immediately following findEND()
> though I am not sure there is a big win overall.
>
> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version o
On Sat, Jan 28, 2023 at 6:06 PM Alan Bateman
wrote:
> 8k is the threshold at which RAF spills into a temporary malloc'ed
> buffer for the I/O operation. At some point the RAF implementation will
> be replaced (we need to do this for a Project Loom), but in the mean
> time, it probably would requi
On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen
wrote:
> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version of the test).
>
Consensus seems to be we leave the existing manual test alone. I've updated
the PR to leave the existing test as-
Hi,
Please review this PR which speeds up ZipFile entry lookup by ~17%, mostly
by removing a string decode / allocation when getEntryPos compares lookup
names with names in the CEN:
https://github.com/openjdk/jdk/pull/12290
Thanks,
Eirik.
On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen
wrote:
> I think it is fine to move the validation immediately following findEND()
> though I am not sure there is a big win overall.
>
> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version o
Please review this documentation-only change which fixes incorrect
capitalization when referencing "aToIndex" and "bToIndex" in the Javadocs
of Arrays.compare and Arrays.mismatch.
https://github.com/openjdk/jdk/pull/12488
Thanks,
Eirik.
Hi!
CorruptedZipFiles could benefit from some modernization and a conversion to
testNG:
https://github.com/openjdk/jdk/pull/12563
Thanks,
Eirik.
Hi,
The following PR suggests we can speed up Character.toUpperCase and
Character.toLowerCase for latin1 code points by applying 'the oldest ASCII
trick in the book':
https://github.com/openjdk/jdk/pull/12623
Thanks,
Eirik.
Hi,
The following PR suggests we can speed up StringLatin1.regionMatchesCI by
applying 'the oldest ASCII trick in the book':
https://github.com/openjdk/jdk/pull/12632
Thanks,
Eirik.
Hi,
This PR continues the effort to speed up case-insensitive string
comparisons, this time tackling comparison of latin1-coded strings with
utf16-coded strings:
https://github.com/openjdk/jdk/pull/12637
This builds on top of #12632, it makes sense to review that one first.
Thanks,
Eirik.
Hi,
So I found myself writing some code which sets up a j.u.s.Stream processing
pipeline where the stream can optionally be traced/logged via a peeking
Consumer.
The default should be not to trace, in which case I initially set the
Consumer to null. But then I need to check that trace != null whe
; will learn how to read and write x -> true and () -> { } and that their
> usage will become idiomatic. Even the value of Function.identity() over x
> -> x is questionable.
Makes sense. And where would we stop..?
EIrik.
On Mon, Feb 20, 2023 at 7:24 PM Eirik Bjørsnøs wrote:
> H
Hi,
While writing various ZIP related tests, I noticed a discrepancy in the
treatment of invalid CRC values:
While ZipInputStream rejects invalid CRC values when consuming streams,
ZipFile and ZipFileSystem do not.
While this is inconsistent, it is perhaps not a bug we want to fix?
In any case,
On Fri, Feb 24, 2023 at 9:22 AM Alan Bateman
wrote:
> As a general point, the ZIP format can have redundant metadata and there
> can be cases where the CRC-32 isn't available when writing a LOC header.
>
ZipInputStream throws exceptions in both of these cases. If the general
purpose bit flag 3 i
>
> Indeed, but I found it a bit amusing that ZipFile (and ZipFileSystem),
> which both see the "full picture", are actually the ones to not enforce the
> CRC.
>
With the current state of affairs, it is conceivable that a single-event
upset could cause an IF_ICMPNE byte code to be flipped into an
Hi,
I noticed that ZipOutputStream violates APPNOTE.txt when writing directory
entries:
Zero-byte files, directories, and other file types that
> contain no content MUST NOT include file data.
Nobody seems to have complained about this violation (I searched JBS), so
in itself it might not be wo
On Mon, Mar 6, 2023 at 8:45 PM Alan Bateman wrote:
> Changing ZOS.putNextEntry to ignore the method/size provided by the
> caller would change long standing behavior, and Hyrum's Law has it that
> somebody will notice.
I was not thinking of changing anything if the caller actually specified a
m
>
> Eirik's mail mentions that 7% of Spring Petclinic dependences are
> directories. It might be interesting to dig into that to see how they
> are generated, is it mostly maven-jar-plugin and if so, which APIs is it
> using?
>
Some stats:
Of 109 JAR files, 2 do not have a manifest file, and 28 d
On Mon, Mar 6, 2023 at 9:33 PM Lance Andersen
wrote:
> Adding an API Note will require a CSR.
>
Lance, Alan
Seems we reached consensus that the right thing to do here is to add an
`@apiNote`
Here's a draft PR with a suggested CSR:
https://github.com/openjdk/jdk/pull/12899
Thanks,
Eirik.
>
> It would require re-specifying ZOS.setMethod to set the default
> compression method for non-directory entries and re-specifying
> ZOS.putNextEntry to use the STORED method as the default for directory
> entries. Even so, this wouldn't ensure that directory entries have 0 size.
> Given that ZOS
>
> For the note then you might want to change it to "ZipEntry e = ..."
> because the reader see the trailing slash after dir so it is obviously a
> directory.
>
That does indeed make more sense for the general case.
> Also the javadoc uses "crc-32" rather than "crc" should we should keep
> that
On Fri, Mar 17, 2023 at 12:00 PM Jaikiran Pai
wrote:
> Additional details in that issue state that the JDK being used is Java 15.
> There have been code changes in this piece of code in java.util.zip.ZipFile
> since then.
>
Looks to me like an instance of JDK-8260010 [1], which was a thread-safe
>
> The fix was backported to 15, not sure which build it was included in.
>
Sorry, seems the fix was backported to 16, not 15.
The recommendation would still be the same: Upgrade to a more recent JDK
release. 17 is the current LTS release.
Eirik.
Hi,
I'll raise this periodic (?) question for discussion, but first I want to
make it clear I have no opinion myself.
Here is the question in question:
Should jextract be extracted from the JDK? If so, would it make sense to do
it now rather than later?
I'm asking this because I remember this b
github.com/openjdk/jextract
>
> For which binary snapshots are also provided here:
>
> https://jdk.java.net/jextract/
>
> (this change happened roughly an year ago [1]).
>
> Cheers
> Maurizio
>
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2022-March
On Wed, Apr 12, 2023 at 10:27 PM Roger Riggs wrote:
> Hi,
>
> The status quo takes a balance between trying do the right thing and
> creating a headache for lots of developers.
> Deprecating the existing methods would cause lots of warnings and
> provide little actual improvement.
>
It is a matt
Hi,
My understanding of the review process for release notes is a bit sketchy,
I could need some clarification.
Consider my release note for JDK-8205129 Remove java.lang.Compiler as an
example:
https://bugs.openjdk.org/browse/JDK-8304459
The PR is approved and integrated and the issue Resolved
>
> https://openjdk.org/guide/#release-notes
Thanks David, I just found this and it seems to answer most of my
questions. It does not explicitly say that the release note is considered
approved when the PR is approved, but I guess I'm safe to assume so.
Cheers,
Eirik.
Hello,
During a discussion about the deprecation of String.toLowerCase(),
String.toUpperCase [1], it occurred to me that the current Note in the API
documentation could be more specific when talking about locales.
Before going ahead and suggesting a PR/CSR, I'd like to socialize the idea
that we
>
> Any thoughts?
>
I'll add my own thoughts, which is that busy developers cannot be expected
to do the "right thing" if they don't understand the API Note.
Improving the note such that more developers understand the consequences of
using the method should help developers write more correct code
>
>
> Unless your reviewers indicate they have seen the Release Note I would
> not assume that. If unclear ask someone to add a comment to the JBS
> issue saying they think it is okay.
>
This was very useful.
Thank,
Eirik.
>
> In that case, isn't there something a little backwards about saying we
> should continue sweeping them under the rug? (Am I being too idealistic?)
>
I sympathise with the concern of causing many warnings/errors, and the
right time to do these things never seems to be "now".
But let's look at
Hi,
JDK-4512189 [1] raised the issue that ZipFile, ZipEntry, ZipInputStream and
ZipOutputStream all implement the non-public ZipConstants interface. While
the interface itself is non-public, the constants defined unfortunately
leak into the public API as constants of the mentioned classes. This me
On Tue, Nov 28, 2023 at 5:28 PM David Lloyd wrote:
> I agree, I always thought that this was a bizarre thing to expose in a
> public API so it being accidental does explain things. But maybe the
> appropriate fix is even simpler now in these modern times: one could remove
> the `implements` and a
On Tue, Nov 28, 2023 at 6:16 PM Alan Bateman
wrote:
> > In light of this, I would like to revisit this issue, 22 years later:
> [...]
>
> This is a JDK 1.1 era mistake. It would a source incompatible change to
> "remove" the constants. It would require corpus searches to gauge the
> impact. I t
>
> But keeping this "peculiarity" afloat does not come for free either.
>
Let me add that keeping the constants also incurs a maintenance cost: The
fact that these constants are "effectively and accidentally public" is
unusual, but needs to be understood and enforced by maintainers. Their
names,
On Tue, Nov 28, 2023 at 6:16 PM Alan Bateman
wrote:
> This is a JDK 1.1 era mistake. It would a source incompatible change to
> "remove" the constants. It would require corpus searches to gauge the
> impact.
Alan,
I've tried to assess the impact by using Github's Code Search. As far as I
can t
Alan,
ZipOutputStream is a relatively high-level API for producing ZIP files.
There are many shapes and corner cases allowed by APPNOTE.TXT which
ZipOutputStream has no means to produce. So while exposing the "external
file attributes" field (which was incorrectly named "extraAttributes" in
ZipEnt
On Mon, 11 Dec 2023 15:38:28 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which adds validation of incorrect LOC signatures in
> `ZipFileSystem`.
>
> `ZipFile` already rejects the case where the offset pointed to from the CEN
> header does not start with the expected LO
Please review this test-only PR which adds test coverage for `ZipFile.getEntry`
under certain charset conditions.
When `ZipFile.getEntry` is called for an entry which has the `Language encoding
flag` general purpose bit flag set, then `ZipCoder.UTF8` is used
unconditionally, even when a diffe
erify the `Language encoding flag` condition for
> `ZipFile.getEntry`.
>
> Testing: Verified that the test indeed fails when
> `ZipFile.Source.getEntryPos` is updated to use the ZipFile's ZipCoder as
> suggested above.
Eirik Bjørsnøs has updated the pull request increme
On Sun, 31 Dec 2023 21:14:54 GMT, Lance Andersen wrote:
> With the conversion, I probably would would at separating out the test runs
> for ZipFile and ZipInputStream and introduce a DataProvider.
Thanks, I separated into two top-level parameterized tests as suggested. Indeed
this was much cle
On Mon, 1 Jan 2024 08:35:17 GMT, Alan Bateman wrote:
> So I think create a new issue for the test work or else change the title on
> this one.
Filed a new issue [JDK-8322802](https://bugs.openjdk.org/browse/JDK-8322802)
for tracking this PR.
-
PR Comment: https://git.openjdk.org/
erify the `Language encoding flag` condition for
> `ZipFile.getEntry`.
>
> Testing: Verified that the test indeed fails when
> `ZipFile.Source.getEntryPos` is updated to use the ZipFile's ZipCoder as
> suggested above.
Eirik Bjørsnøs has updated the pull request incremental
Please consider this PR which makes `DeflaterOutputStream.close()` always close
its wrapped output stream.
Currently, closing of the wrapped output stream happens outside the finally
block where `finish()` is called. If `finish()` throws, this means the wrapped
stream will not be closed. This c
fication.
>
> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which
> simulates the failure condition and verifies that the wrapped stream was
> closed under failing and non-failing conditions.
Eirik Bjørsnøs has updated the pull request incrementally with one additio
On Tue, 2 Jan 2024 08:35:47 GMT, Jaikiran Pai wrote:
> This call has a potential to throw an `IOException` in which case any
> original `IOException` thrown from the `finish()` call will be lost.
Good catch. Adopted your suggestion with a few changes:
- The catch for IOException during finish(
erify the `Language encoding flag` condition for
> `ZipFile.getEntry`.
>
> Testing: Verified that the test indeed fails when
> `ZipFile.Source.getEntryPos` is updated to use the ZipFile's ZipCoder as
> suggested above.
Eirik Bjørsnøs has updated the pull request incremen
On Tue, 2 Jan 2024 07:43:03 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add @bug tag for 8322802
>
> test/jdk/java/util/zip/Zi
On Tue, 2 Jan 2024 08:02:46 GMT, Jaikiran Pai wrote:
> The change to allow user/application specific arbritary charsets to the
> `ZipFile` constructor seems to have been done long back in Java 1.7 days as
> part of https://bugs.openjdk.org/browse/JDK-4244499.
>
> This is merely an observation
fication.
>
> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which
> simulates the failure condition and verifies that the wrapped stream was
> closed under failing and non-failing conditions.
Eirik Bjørsnøs has updated the pull request incrementally with two additiona
On Tue, 2 Jan 2024 10:37:55 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Prevent IOException thrown during finish() from being lost if an
>> IOException is th
sted.
>
> `StreamZipEntriesTest.java`
> This test was using TestNG so was converted to JUnit for consistency. Added
> some comments to help understanding.
>
> `ReadAfterClose.java`
> This uses the binary test vector `crash.jar`. The test is converted to JUnit
> and moved to `Re
On Tue, 2 Jan 2024 16:43:29 GMT, Lance Andersen wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add more cases for 'language encoding' bit set, opened with a different
>
erify the `Language encoding flag` condition for
> `ZipFile.getEntry`.
>
> Testing: Verified that the test indeed fails when
> `ZipFile.Source.getEntryPos` is updated to use the ZipFile's ZipCoder as
> suggested above.
Eirik Bjørsnøs has updated the pull request increment
1 - 100 of 503 matches
Mail list logo
