-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P2
-
Affects Version/s: 23
-
Component/s: core-libs
Read performance has degraded since JDK 23 in GZIPInputStream, after a change in JDK-7036144 causes an IOException to be thrown when checking for additional headers at the end of a stream. A common use case is to read single / one-shot compressed data streams from a byte array or from a socket, so the issue shows up in real world applications.
The specific code that is causing the performance regression is the one here that checks for the next header in the concatenated case: https://github.com/openjdk/jdk/blob/7c979c148724ab7de650593caa22df8405d740e5/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#L261-L267
The specific code that is causing the performance regression is the one here that checks for the next header in the concatenated case: https://github.com/openjdk/jdk/blob/7c979c148724ab7de650593caa22df8405d740e5/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#L261-L267
- caused by
-
JDK-7036144 GZIPInputStream readTrailer uses faulty available() test for end-of-stream
-
- Closed
-
- links to
-
Review(master)
openjdk/jdk/29092