Re: RFR: 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder [v5]

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename > createJavaProcessBuilder' changed the name of the ProcessTools helper > functions used to create `ProcessBuilder`s used to spawn new java test > processes. > > We now have `createTestJavaProcessBuilder` and >

Integrated: 8321718: ProcessTools.executeProcess calls waitFor before logging

On Mon, 11 Dec 2023 11:16:05 GMT, Stefan Karlsson wrote: > There is some logging printed when tests spawns processes. This logging is > triggered from calls to `OutputAnalyzer`, when it delegates calls to > `LazyOutputBuffer`. > > If we write code like this: > > ProcessBuilder pb =

RFR: JDK-8322878: Including sealing information Class.toGenericString()

As recently discussed on core libs, sealed-ness information could be included in the Class.toGenericString() output, analagous to how "modifiers" that also correspond to JVM access flags are handled. This is the initial spec, implementation, and test updated needed for that change. If there is

Re: Blessed modifier order does not include sealed/non-sealed

Note that in terms of updating the implementation of toGenericString() JDK-8322878 to included sealed information, since strictfp is a no-op in the same release sealed/non-sealed was added, a class file can be     sealed XOR strictfp Therefore, Class.toGenericString() could print the

Re: Blessed modifier order does not include sealed/non-sealed

Hello, Some time back, the java.lang.reflect package level docs had a brief discussion added concerning what exactly core reflection is modeling. [1]. tl;dr -- mostly a class file level view. As such, a contingent property of the design of JEP 409 is that sealed/non-sealed happens to _not_

Re: RFR: 8322322: Support archived full module graph when -Xbootclasspath/a is used [v3]

> Please review this change for enabling full module graph even when > -Xbootclasspath/a is specified. The validation of -Xbootclasspath/a is > already being done in `FileMapInfo::validate_boot_class_paths()`. The full > module graph will be disabled if there's a mismatch in -Xbootclasspath/a

Re: Blessed modifier order does not include sealed/non-sealed

While we are here, I also note that the script does not explicitly take into account the `default` modifier on an interface method. However, after reading https://docs.oracle.com/javase/specs/jls/se21/html/jls-9.html#jls-9.4 it seems that whenever `default` appears, it should be alone one way

Re: RFR: 8313739: ZipOutputStream.close() should always close the wrapped stream [v3]

On Tue, 2 Jan 2024 12:21:21 GMT, Eirik Bjørsnøs wrote: >> Please consider this PR which makes `DeflaterOutputStream.close()` always >> close its wrapped output stream exactly once. >> >> Currently, closing of the wrapped output stream happens outside the finally >> block where `finish()` is

Integrated: 8322868: java/io/BufferedInputStream/TransferToTrusted.java has bad copyright header

On Tue, 2 Jan 2024 20:27:29 GMT, Brian Burkhalter wrote: > Add missing comma after 2024. This pull request has now been integrated. Changeset: c2477a5c Author:Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/c2477a5cad6539e6e38cc0732383aaa2a8df801f Stats: 1 line in 1

Re: RFR: 8322868: java/io/BufferedInputStream/TransferToTrusted.java has bad copyright header

On Tue, 2 Jan 2024 20:27:29 GMT, Brian Burkhalter wrote: > Add missing comma after 2024. Thumbs up. This is a trivial fix. - Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17228#pullrequestreview-1800974980

Integrated: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag

On Sun, 31 Dec 2023 18:07:33 GMT, Eirik Bjørsnøs wrote: > 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

RFR: 8322868: java/io/BufferedInputStream/TransferToTrusted.java has bad copyright header

Add missing comma after 2024. - Commit messages: - 8322868: java/io/BufferedInputStream/TransferToTrusted.java has bad copyright header Changes: https://git.openjdk.org/jdk/pull/17228/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17228=00 Issue:

Re: RFR: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag [v6]

On Tue, 2 Jan 2024 17:50:51 GMT, Eirik Bjørsnøs wrote: >> 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

Integrated: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted

On Wed, 29 Nov 2023 11:57:37 GMT, Sergey Tsypanov wrote: > It looks like we can skip copying of `byte[]` in > `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in > `java.io`. > > See comment by @vlsi in >

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v20]

> It looks like we can skip copying of `byte[]` in > `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in > `java.io`. > > See comment by @vlsi in > https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v20]

On Tue, 2 Jan 2024 20:00:36 GMT, Sergey Tsypanov wrote: >> It looks like we can skip copying of `byte[]` in >> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in >> `java.io`. >> >> See comment by @vlsi in >>

Re: Blessed modifier order does not include sealed/non-sealed

- Original Message - > From: "Pavel Rappo" > To: "Roger Riggs" > Cc: "core-libs-dev" > Sent: Tuesday, January 2, 2024 5:31:06 PM > Subject: Re: Blessed modifier order does not include sealed/non-sealed > Hi Roger, > > Happy New Year to you too! > > Although it's a _somewhat_ separate

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v16]

On Thu, 21 Dec 2023 17:29:16 GMT, Brian Burkhalter wrote: >> Sergey Tsypanov 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. The pull request contains 20 additional >>

Re: RFR: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag [v6]

> 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

Re: Blessed modifier order does not include sealed/non-sealed

Hi Pavel, I agree, the script should refer to the JLS. Some people look to the javadoc but its not authoritative on the language. Roger On 1/2/24 12:18 PM, Pavel Rappo wrote: Right, the language model (javax.lang.model) is a better target to refer to when considering _source_ files. However,

Re: RFR: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag [v5]

> 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

Re: RFR: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag [v4]

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 >> encoding > >

Re: Blessed modifier order does not include sealed/non-sealed

Right, the language model (javax.lang.model) is a better target to refer to when considering _source_ files. However, java.lang.reflect.Modifier corresponds to a set returned by javax.lang.model.element.Element#getModifiers, not to a single instance of javax.lang.model.element.Modifier; the

Re: Blessed modifier order does not include sealed/non-sealed

Hi Pavel, It better to look to javax.lang.model.element.Modifier for the language view of the class. java.lang.reflect.Modifier covers the modifier flags as represented in the class

Re: RFR: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag [v4]

On Tue, 2 Jan 2024 09:31:16 GMT, Eirik Bjørsnøs wrote: >> 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

Re: Blessed modifier order does not include sealed/non-sealed

Hi Roger, Happy New Year to you too! Although it's a _somewhat_ separate issue, I found that the shell script refers to java.lang.reflect.Modifier#toString which does NOT mention either `sealed` or `non-sealed`. More precisely, the script refers to the JDK 8 version of that method, but [the

Re: RFR: 8322027: One XMLStreamException constructor fails to initialize cause

On Tue, 2 Jan 2024 06:47:52 GMT, Jaikiran Pai wrote: >> One of the three `XMLStreamException` constructors that takes a `Throwable` >> fails to pass it to the superclass constructor. >> >> This simple patch fixes that omission. >> >> It's worth considering if there is any code out there that

Re: RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang

On Tue, 2 Jan 2024 15:56:06 GMT, Jaikiran Pai wrote: > I guess that then means that the some pinned threads might not even appear in > this generated thread dumps. Just to be clear. The changes here have no impact on thread dumps, the thread dump generated by jcmd Thread.dump_to_file has all

Re: RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang

On Tue, 2 Jan 2024 13:53:39 GMT, Alan Bateman wrote: > -Djdk.tracePinnedThreads is a debugging option that dates from early > development in the loom repo to identify pinned threads. It has several > issues and this tracing option will eventually be removed (use JFR events > instead). Several

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v19]

On Sat, 30 Dec 2023 16:47:11 GMT, Sergey Tsypanov wrote: >> It looks like we can skip copying of `byte[]` in >> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in >> `java.io`. >> >> See comment by @vlsi in >>

Re: RFR: 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder [v3]

On Mon, 11 Dec 2023 14:06:43 GMT, Stefan Karlsson wrote: >> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename >> createJavaProcessBuilder' changed the name of the ProcessTools helper >> functions used to create `ProcessBuilder`s used to spawn new java test >> processes. >>

Re: RFR: 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder [v4]

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename > createJavaProcessBuilder' changed the name of the ProcessTools helper > functions used to create `ProcessBuilder`s used to spawn new java test > processes. > > We now have `createTestJavaProcessBuilder` and >

Re: RFR: 8321718: ProcessTools.executeProcess calls waitFor before logging [v2]

On Tue, 12 Dec 2023 09:01:08 GMT, Stefan Karlsson wrote: >> There is some logging printed when tests spawns processes. This logging is >> triggered from calls to `OutputAnalyzer`, when it delegates calls to >> `LazyOutputBuffer`. >> >> If we write code like this: >> >> ProcessBuilder pb =

Re: RFR: 8321718: ProcessTools.executeProcess calls waitFor before logging [v3]

> There is some logging printed when tests spawns processes. This logging is > triggered from calls to `OutputAnalyzer`, when it delegates calls to > `LazyOutputBuffer`. > > If we write code like this: > > ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...); > OutputAnalyzer

RFR: 8322818: Thread::getStackTrace can fail with InternalError if virtual thread is timed-parked when pinned

Missed by JDK-8312498, VirtualThread::tryGetStackTrace doesn't handle the TIMED_PINNED state so it's possible for Thread::getStackTrace to throw InternalError when invoked on a virtual thread that quickly transitions from unmounted to timed-park-while-pinned. This one is needs a stress test to

RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang

-Djdk.tracePinnedThreads is a debugging option that dates from early development in the loom repo to identify pinned threads. It has several issues and this tracing option will eventually be removed (use JFR events instead). Several hangs have been reported when running with the system property

RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock

In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of

Re: RFR: 8320707: Virtual thread test updates [v2]

> A lot of test changes have accumulated in the loom repo, this includes both > new tests and updates to existing tests. Some of these updates can be brought > to the main line. This update brings over: > > - The existing tests for pinning use synchronized blocks. In preparation for > changes

Re: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue) [v4]

> This PR adds an internal method to calculate hash code from the provided > integer array, offset and length into that array, and the initial hash code > value. > > Current options for calculating a hash code for int[] are inflexible. It's > either ArraysSupport.vectorizedHashCode with an

Re: Blessed modifier order does not include sealed/non-sealed

Hi Pavel, yes, a PR would be next. Happy New Year, Roger On 1/2/24 7:08 AM, Pavel Rappo wrote: I assume the order for `sealed` and `non-sealed` has effectively been decided by JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1 8.1.1. Class Modifiers ...

Re: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v10]

> Please review this PR to use modern APIs and language features to simplify > equals, hashCode, and compareTo for BigInteger. If you have any performance > concerns, please raise them. > > This PR is cherry-picked from a bigger, not-yet-published PR, to test the > waters. That latter PR will

Re: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs [v2]

On Fri, 10 Nov 2023 15:44:19 GMT, Yakov Shafranovich wrote: >> The various Zip/Jar-file related Java APIs have some long-standing >> differences or peculiarities with respect to the ZIP-file specification or >> compared to other implementations which should be documented in the API-doc. >>

Re: RFR: 8321616: Retire binary test vectors in test/jdk/java/util/zip/ZipFile [v9]

> This PR suggests we retire the binary test vectors `ZipFile/input.zip`, > `ZipFile/input.jar` and `ZipFile/crash.jar` > > Binary test vectors are harder to analyze, and sharing test vectors across > unrelated tests increases maintenance burden. It would be better to have each > test produce

Re: RFR: 8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown [v2]

On Thu, 7 Dec 2023 07:53:58 GMT, Adam Sotona wrote: >> ClassFile API throws `IndexOutOfBoundsException` when classfile structure is >> corrupted so the parser attempts to read beyond the classfile bounds. >> General contract is that only `IllegalArgumentException` or its subclasses >> is

Integrated: 8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown

On Tue, 21 Nov 2023 13:59:23 GMT, Adam Sotona wrote: > ClassFile API throws `IndexOutOfBoundsException` when classfile structure is > corrupted so the parser attempts to read beyond the classfile bounds. > General contract is that only `IllegalArgumentException` or its subclasses is > expected

Re: RFR: 8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown [v2]

On Tue, 2 Jan 2024 07:03:55 GMT, Jaikiran Pai wrote: >> Adam Sotona has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' into JDK-8320360-bounds >> >># Conflicts: >>#

Re: RFR: 8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown [v3]

> ClassFile API throws `IndexOutOfBoundsException` when classfile structure is > corrupted so the parser attempts to read beyond the classfile bounds. > General contract is that only `IllegalArgumentException` or its subclasses is > expected when parser fails. > This patch wraps

Re: RFR: 8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown [v2]

On Tue, 2 Jan 2024 12:41:08 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java >> line 283: >> >>> 281: public void copyBytesTo(BufWriter buf, int p, int len) { >>> 282: try { >>> 283: buf.writeBytes(buffer, p, len);

Re: RFR: 8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown [v2]

On Tue, 2 Jan 2024 07:05:22 GMT, Jaikiran Pai wrote: >> Adam Sotona has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' into JDK-8320360-bounds >> >># Conflicts: >>#

Integrated: 8321540: ClassSignature.parseFrom() throws StringIndexOutOfBoundsException for invalid signatures

On Mon, 11 Dec 2023 15:17:49 GMT, Adam Sotona wrote: > ClassFile API models and parses signatures, however parsing of the signatures > mostly throws IIOBE when it fails. > This patch improves SignaturesImpl parsing methods implementation and errors > handling and adds relevant negative tests.

Re: RFR: 8321540: ClassSignature.parseFrom() throws StringIndexOutOfBoundsException for invalid signatures [v2]

On Tue, 2 Jan 2024 07:17:46 GMT, Jaikiran Pai wrote: > I'm guessing you have intentionally not included the original > `IndexOutOfBoundsException` as a cause in the `IllegalArgumentException` that > gets thrown. Yes, original exception does not contain any meaningful information. > Also, it

Re: RFR: 8321540: ClassSignature.parseFrom() throws StringIndexOutOfBoundsException for invalid signatures [v2]

> ClassFile API models and parses signatures, however parsing of the signatures > mostly throws IIOBE when it fails. > This patch improves SignaturesImpl parsing methods implementation and errors > handling and adds relevant negative tests. > The parser is not an ultimate signatures validator

Re: RFR: 8313739: ZipOutputStream.close() should always close the wrapped stream [v2]

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 thrown while closing the wrapped

Re: RFR: 8313739: ZipOutputStream.close() should always close the wrapped stream [v3]

> 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

Re: RFR: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag [v4]

On Tue, 2 Jan 2024 09:31:16 GMT, Eirik Bjørsnøs wrote: >> 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

Re: Blessed modifier order does not include sealed/non-sealed

- Original Message - > From: "Pavel Rappo" > To: "core-libs-dev" > Sent: Tuesday, January 2, 2024 12:56:08 PM > Subject: Blessed modifier order does not include sealed/non-sealed > I couldn't find any prior discussions on this matter. > > I noticed that bin/blessed-modifier-order.sh

Re: Blessed modifier order does not include sealed/non-sealed

I assume the order for `sealed` and `non-sealed` has effectively been decided by JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1 8.1.1. Class Modifiers ... ClassModifier: (one of) Annotation public protected private abstract static final

Blessed modifier order does not include sealed/non-sealed

I couldn't find any prior discussions on this matter. I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note that we already have cases in OpenJDK where those keywords are

Integrated: 8317846: Typo in API documentation of classes IdentityHashMap

On Wed, 11 Oct 2023 04:45:20 GMT, ANUPAM DEV wrote: > Hello, > > I have fixed the typo in the comment for the constructor > IdentityHashMap(Map m) > > before: Constructs a new identity hash map containing the keys-value mappings > in the specified map. > after: Constructs a new identity hash

Re: RFR: 8313739: ZipOutputStream.close() should always close the wrapped stream [v2]

On Tue, 2 Jan 2024 09:14:14 GMT, Eirik Bjørsnøs wrote: >> 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

Integrated: 8322027: One XMLStreamException constructor fails to initialize cause

On Wed, 13 Dec 2023 20:06:03 GMT, Archie Cobbs wrote: > One of the three `XMLStreamException` constructors that takes a `Throwable` > fails to pass it to the superclass constructor. > > This simple patch fixes that omission. > > It's worth considering if there is any code out there that is

Re: RFR: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag [v4]

On Tue, 2 Jan 2024 09:31:16 GMT, Eirik Bjørsnøs wrote: >> 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

Re: RFR: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag [v3]

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

Re: RFR: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag [v3]

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/ZipCoding.java line 86: > >> 84: //

Re: RFR: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag [v4]

> 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

Re: RFR: 8313739: ZipOutputStream.close() should always close the wrapped stream [v2]

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

Re: RFR: 8313739: ZipOutputStream.close() should always close the wrapped stream [v2]

> 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

Re: RFR: 8313739: ZipOutputStream.close() should always close the wrapped stream

On Mon, 1 Jan 2024 16:12:13 GMT, Eirik Bjørsnøs wrote: > Specification: This change brings the implementation of > DeflaterOutputStream.close() in line with its specification: Writes remaining > compressed data to the output stream and closes the underlying stream. > Risk: This is a

Re: RFR: 8322802: Add testing for ZipFile.getEntry respecting the 'Language encoding' flag [v3]

On Mon, 1 Jan 2024 14:29:50 GMT, Eirik Bjørsnøs wrote: >> 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