Re: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v3]
On Fri, 22 Oct 2021 10:44:31 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which fixes the issue reported in >> https://bugs.openjdk.java.net/browse/JDK-8275509? >> >> The `ModuleDescriptor.hashCode()` method uses the hash code of its various >> components to compute the final hash code. While doing so it ends up calling >> hashCode() on (collection of) various `enum` types. Since the hashCode() of >> enum types is generated from a call to `java.lang.Object.hashCode()`, their >> value isn't guaranteed to stay the same across multiple JVM runs. >> >> The commit here proposes to use the ordinal of the enum as the hash code. As >> Alan notes in the mailing list discussion, any changes to the ordinal of the >> enum (either due to addition of new value, removal of a value or just >> reordering existing values, all of which I think will be rare in these >> specific enum types) isn't expected to produce the same hash code across >> those changed runtimes and that should be okay. >> >> The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart >> from calls to the enum types hashCode(), rest of the calls in that >> implementation, either directly or indirectly end up as calls on >> `java.lang.String.hashCode()` and as such aren't expected to cause >> non-deterministic values. >> >> A new jtreg test has been added to reproduce this issue and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional > commit since the last revision: > > drop another final to make it consistent with rest of the code test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 159: > 157: } > 158: } > 159: } It seems you're missing a newline at the EOF. - PR: https://git.openjdk.java.net/jdk/pull/6078
Re: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v4]
> Can I please get a review for this change which fixes the issue reported in > https://bugs.openjdk.java.net/browse/JDK-8275509? > > The `ModuleDescriptor.hashCode()` method uses the hash code of its various > components to compute the final hash code. While doing so it ends up calling > hashCode() on (collection of) various `enum` types. Since the hashCode() of > enum types is generated from a call to `java.lang.Object.hashCode()`, their > value isn't guaranteed to stay the same across multiple JVM runs. > > The commit here proposes to use the ordinal of the enum as the hash code. As > Alan notes in the mailing list discussion, any changes to the ordinal of the > enum (either due to addition of new value, removal of a value or just > reordering existing values, all of which I think will be rare in these > specific enum types) isn't expected to produce the same hash code across > those changed runtimes and that should be okay. > > The rest of the ModuleDescriptor.hashCode() has been reviewed too and apart > from calls to the enum types hashCode(), rest of the calls in that > implementation, either directly or indirectly end up as calls on > `java.lang.String.hashCode()` and as such aren't expected to cause > non-deterministic values. > > A new jtreg test has been added to reproduce this issue and verify the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: add newline at end of test class - Changes: - all: https://git.openjdk.java.net/jdk/pull/6078/files - new: https://git.openjdk.java.net/jdk/pull/6078/files/89669ea4..006255d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6078&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6078&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6078.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6078/head:pull/6078 PR: https://git.openjdk.java.net/jdk/pull/6078
Re: RFR: 8275509: ModuleDescriptor.hashCode isn't reproducible across builds [v3]
On Mon, 25 Oct 2021 08:04:43 GMT, Magnus Ihse Bursie wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> drop another final to make it consistent with rest of the code > > test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java line 159: > >> 157: } >> 158: } >> 159: } > > It seems you're missing a newline at the EOF. Indeed. Updated the PR to fix it. - PR: https://git.openjdk.java.net/jdk/pull/6078
Re: RFR: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout
On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a > timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The > timeout seems to have happened even after the tests had already completed > successfully. Like I note in the JBS comments of that issue, I suspect it > might have to do with the > "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in > this test action. > > The commit in this PR removes that second `@test` altogether because (correct > me if I'm wrong) from what I understand, this test never enables the > DeserializationEvent which means there is no JFR events being captured for > deserialization in this test, nor does the test do any JFR events related > testing. So, I think this second `@test` is virtually a no-op when it comes > to the JFR testing. There's a separate `TestDeserializationEvent` which has a > comprehensive testing of the DeserializationEvent. Thank you for the review Chris. Roger, should I go ahead with the merge? - PR: https://git.openjdk.java.net/jdk/pull/6008
RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings
Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: Before: Benchmark (size) (type) Mode Cnt Score Error Units CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ± 0.120 us/op CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ± 1.942 us/op CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ± 2.006 us/op CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ± 5.019 us/op CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ± 1.651 us/op Patched: Benchmark (size) (type) Mode Cnt Score Error Units CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ± 0.078 us/op CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ± 0.209 us/op CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ± 0.251 us/op CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ± 0.368 us/op CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ± 0.267 us/op The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. Testing: tier1-3 - Commit messages: - Use field directly - Grant accessClassInPackage.jdk.internal.access permission to jdk.charsets module - 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings Changes: https://git.openjdk.java.net/jdk/pull/6102/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6102&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275863 Stats: 35 lines in 5 files changed: 24 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6102/head:pull/6102 PR: https://git.openjdk.java.net/jdk/pull/6102
Re: RFR: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout
On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a > timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The > timeout seems to have happened even after the tests had already completed > successfully. Like I note in the JBS comments of that issue, I suspect it > might have to do with the > "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in > this test action. > > The commit in this PR removes that second `@test` altogether because (correct > me if I'm wrong) from what I understand, this test never enables the > DeserializationEvent which means there is no JFR events being captured for > deserialization in this test, nor does the test do any JFR events related > testing. So, I think this second `@test` is virtually a no-op when it comes > to the JFR testing. There's a separate `TestDeserializationEvent` which has a > comprehensive testing of the DeserializationEvent. LGTM - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6008
Re: RFR: 8270490: Charset.forName() taking fallback default value [v4]
On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to >> `Charset.forName()` was suggested >> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This >> PR is to implement the proposal. A CSR is also drafted as >> https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Reflecting review comments Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6045
Re: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v4]
> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. > After JDK18-b13, javac and some other langtool command's usage were garbled > on Japanese Windows. > These commands use PrintWriter instead of standard out/err with PrintStream. Ichiroh Takiguchi 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 four additional commits since the last revision: - 8274544: Langtools command's usage were garbled on Japanese Windows - 8274544: Langtools command's usage were garbled on Japanese Windows - 8274544: Langtools command's usage were garbled on Japanese Windows - Langtools command's usage were grabled on Japanese Windows - Changes: - all: https://git.openjdk.java.net/jdk/pull/5771/files - new: https://git.openjdk.java.net/jdk/pull/5771/files/4427d87c..e2a87848 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=02-03 Stats: 35926 lines in 1051 files changed: 24201 ins; 7865 del; 3860 mod Patch: https://git.openjdk.java.net/jdk/pull/5771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771 PR: https://git.openjdk.java.net/jdk/pull/5771
Re: RFR: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout
On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a > timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The > timeout seems to have happened even after the tests had already completed > successfully. Like I note in the JBS comments of that issue, I suspect it > might have to do with the > "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in > this test action. > > The commit in this PR removes that second `@test` altogether because (correct > me if I'm wrong) from what I understand, this test never enables the > DeserializationEvent which means there is no JFR events being captured for > deserialization in this test, nor does the test do any JFR events related > testing. So, I think this second `@test` is virtually a no-op when it comes > to the JFR testing. There's a separate `TestDeserializationEvent` which has a > comprehensive testing of the DeserializationEvent. Thank you Roger. - PR: https://git.openjdk.java.net/jdk/pull/6008
Integrated: 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout
On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote: > The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a > timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The > timeout seems to have happened even after the tests had already completed > successfully. Like I note in the JBS comments of that issue, I suspect it > might have to do with the > "-XX:StartFlightRecording:name=DeserializationEvent,dumponexit=true" usage in > this test action. > > The commit in this PR removes that second `@test` altogether because (correct > me if I'm wrong) from what I understand, this test never enables the > DeserializationEvent which means there is no JFR events being captured for > deserialization in this test, nor does the test do any JFR events related > testing. So, I think this second `@test` is virtually a no-op when it comes > to the JFR testing. There's a separate `TestDeserializationEvent` which has a > comprehensive testing of the DeserializationEvent. This pull request has now been integrated. Changeset: f143d2a8 Author:Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/f143d2a88e1972cdce9eb6f61c2eb9754cb89251 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout Reviewed-by: chegar, rriggs - PR: https://git.openjdk.java.net/jdk/pull/6008
Re: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v4]
On Mon, 25 Oct 2021 14:20:52 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi 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 four additional
> commits since the last revision:
>
> - 8274544: Langtools command's usage were garbled on Japanese Windows
> - 8274544: Langtools command's usage were garbled on Japanese Windows
> - 8274544: Langtools command's usage were garbled on Japanese Windows
> - Langtools command's usage were grabled on Japanese Windows
Terminal setting
$ locale
LANG=ja_JP.eucjp
LC_CTYPE="ja_JP.eucjp"
LC_NUMERIC="ja_JP.eucjp"
LC_TIME="ja_JP.eucjp"
LC_COLLATE="ja_JP.eucjp"
LC_MONETARY="ja_JP.eucjp"
LC_MESSAGES="ja_JP.eucjp"
LC_PAPER="ja_JP.eucjp"
LC_NAME="ja_JP.eucjp"
LC_ADDRESS="ja_JP.eucjp"
LC_TELEPHONE="ja_JP.eucjp"
LC_MEASUREMENT="ja_JP.eucjp"
LC_IDENTIFICATION="ja_JP.eucjp"
LC_ALL=
Java testcase by using Scanner.
$ cat scan.java
import java.util.*;
public class scan {
public static void main(String[] args) throws Exception {
System.out.println("Please input some characters:");
Scanner scanner = new Scanner(System.in);
System.out.println(scanner.next());
}
}
$ ~/jdk-18-b19/bin/java scan.java
Please input some characters:
あいうえお
??
When
`src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java`
is modified
$ jshell
| JShellへようこそ -- バージョン18-internal
| 概要については、次を入力してください: /help intro
jshell> import java.nio.charset.*
jshell> System.out.println(System.getProperty("native.encoding"))
EUC-JP-LINUX
jshell> System.out.println(Charset.defaultCharset())
UTF-8
jshell> var scan = new Scanner(System.in)
scan ==> java.util.Scanner[delimiters=\p{javaWhitespace}+] ... \E][infinity
string=\Q∞\E]
jshell> var s = scan.next()
あいうえお
s ==> "あいうえお"
jshell> System.out.println(s)
あいうえお
jshell> /exit
| 終了します
$
-
PR: https://git.openjdk.java.net/jdk/pull/5771
RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets
Trivial clean-up. - Commit messages: - 8275767: JDK source code contains redundant boolean operations in jdk.charsets Changes: https://git.openjdk.java.net/jdk/pull/6110/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6110&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275767 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6110/head:pull/6110 PR: https://git.openjdk.java.net/jdk/pull/6110
Re: RFR: 8270490: Charset.forName() taking fallback default value [v4]
On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to >> `Charset.forName()` was suggested >> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This >> PR is to implement the proposal. A CSR is also drafted as >> https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Reflecting review comments Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6045
Re: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets
On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6110
Re: RFR: 8275536: Add test to check that File::lastModified returns same time stamp as Files.getLastModifiedTime [v3]
On Thu, 21 Oct 2021 22:54:34 GMT, Clive Verghese wrote: >> The test validated that the precision returned by >> `java.io.File.lastModified` and `java.nio.file.Files.getLastModifiedTime` >> are the same. > > Clive Verghese has updated the pull request incrementally with one additional > commit since the last revision: > > Move test from java/nio to java/io Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6054
Re: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets
On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. Given that the code has been that way for a *long time*, did you check that both paths work as intended and that tests exist for both paths? - PR: https://git.openjdk.java.net/jdk/pull/6110
Re: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets
On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. No, I did not check. I simply removed the `true &&` as it is logically correct. There's a test specifying `IBM964` in `sun.nio.cs.TestIBMBugs.java`, but not sure it tests both paths or not. - PR: https://git.openjdk.java.net/jdk/pull/6110
Re: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets
On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. LGTM - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6110
Re: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets
On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6110
Integrated: 8275536: Add test to check that File::lastModified returns same time stamp as Files.getLastModifiedTime
On Thu, 21 Oct 2021 00:27:20 GMT, Clive Verghese wrote: > The test validated that the precision returned by `java.io.File.lastModified` > and `java.nio.file.Files.getLastModifiedTime` are the same. This pull request has now been integrated. Changeset: 97d3280e Author:Clive Verghese Committer: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/97d3280eb4735f5b84cd4a9a1286e35c1c48113a Stats: 60 lines in 1 file changed: 60 ins; 0 del; 0 mod 8275536: Add test to check that File::lastModified returns same time stamp as Files.getLastModifiedTime Reviewed-by: alanb, bpb - PR: https://git.openjdk.java.net/jdk/pull/6054
Re: RFR: 8270490: Charset.forName() taking fallback default value [v4]
On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to >> `Charset.forName()` was suggested >> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This >> PR is to implement the proposal. A CSR is also drafted as >> https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Reflecting review comments Thank you for clarification. - Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6045
Re: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v2]
On Tue, 12 Oct 2021 16:21:33 GMT, Mandy Chung wrote: >> Classes compiled prior to the nestmate support will generate >> `REF_invokeSpecial` if the implementation method is a private instance >> method. Since a lambda proxy class is a hidden class, a nestmate of the >> host class, it can invoke the private implementation method but it has to >> use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the >> old classes running on the new runtime, LMF implementation adjusts the >> reference kind from `REF_invokeSpecial` to >> `REF_invokeVirtual/REF_invokeInterface`. >> >> This PR fixes the check properly to ensure the adjustment is only made if >> the implementation method is private method in the host class. > > Mandy Chung has updated the pull request incrementally with one additional > commit since the last revision: > > remove filelist which was added accidentally Source changes look good. The test seems like way too much overhead for this small thing. Looks like a lot of the ASM code is just to verify that javac generates the test case you expect? I'd suggest invoking the LMF API directly instead, testing both private and non-private `invokespecial` MethodHandles, just making sure the rules can be used without error. - PR: https://git.openjdk.java.net/jdk/pull/5901
Re: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec
On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote: > It looks like we cannot use `Long.hashCode(long)` for > `java.rmi.server.ObjID.hashCode()` due to specification: > https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). Just a suggestion, it is always a good thing to add a jtreg test case, especially if it is regression. - PR: https://git.openjdk.java.net/jdk/pull/5963
Re: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec
On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote: > It looks like we cannot use `Long.hashCode(long)` for > `java.rmi.server.ObjID.hashCode()` due to specification: > https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). Oh yes, good point in general. In this case the problem was caught by the failure of a JCK test, so I don't think a separate regression test is necessary. I've added the `noreg-jck` label to the bug to indicate this. - PR: https://git.openjdk.java.net/jdk/pull/5963
Re: RFR: 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec
On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote: > It looks like we cannot use `Long.hashCode(long)` for > `java.rmi.server.ObjID.hashCode()` due to specification: > https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode(). I think this one was missed due to the absence of the coverage in the jtreg test suite, and some people have no access to the jck to run it in advance. - PR: https://git.openjdk.java.net/jdk/pull/5963
Re: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v4]
> Hi all, > > Please review this fix for Infinite loop in ZipOutputStream.close(). > The main issue here is when ever there is an exception during close > operations on GZip we are not setting the deflator to a finished state which > is leading to an infinite loop when we try writing on the same GZip instance( > since we use while(!def.finished()) inside the write operation). > > Thanks, > Ravi Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: 8193682 : Infinite loop in ZipOutputStream.close() - Changes: - all: https://git.openjdk.java.net/jdk/pull/5522/files - new: https://git.openjdk.java.net/jdk/pull/5522/files/d18eb3c1..5f1922bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=02-03 Stats: 26 lines in 2 files changed: 12 ins; 7 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5522/head:pull/5522 PR: https://git.openjdk.java.net/jdk/pull/5522
