Re: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v3]
> Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/the… > > Also, I fixed a couple of spelling mistakes. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Update copyright to 2022 - Changes: - all: https://git.openjdk.java.net/jdk/pull/8768/files - new: https://git.openjdk.java.net/jdk/pull/8768/files/0669cdc1..fa2caaec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01-02 Stats: 102 lines in 102 files changed: 0 ins; 0 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/8768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768 PR: https://git.openjdk.java.net/jdk/pull/8768
Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2]
On Mon, 23 May 2022 18:58:34 GMT, Mark Powers wrote: >> JDK-6725221 Standardize obtaining boolean properties with defaults > > Mark Powers has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains six commits: > > - Alan and Jamil comments > - Merge > - reverse true.equals and false.equals changes > - Merge > - Merge > - first iteration LGTM - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8559
Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2]
On Mon, 23 May 2022 18:34:41 GMT, Roger Riggs wrote: >> You are right. The old way maps the null string to true, and the new way >> maps it to false. I did not notice that. At this point, I see no value in >> making the "true".equals and "false".equals changes. Too much can break. >> I'll reverse these changes. > > This change still needs to be reversed. The change has been reversed. We had an internal discussion about IntelliJ's unboxing recommendation, and decided to let unboxing be a matter of personal preference. Those changes have been reversed too. - PR: https://git.openjdk.java.net/jdk/pull/8559
Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2]
> JDK-6725221 Standardize obtaining boolean properties with defaults Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Alan and Jamil comments - Merge - reverse true.equals and false.equals changes - Merge - Merge - first iteration - Changes: https://git.openjdk.java.net/jdk/pull/8559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8559&range=01 Stats: 9 lines in 3 files changed: 1 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8559/head:pull/8559 PR: https://git.openjdk.java.net/jdk/pull/8559
Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults
On Tue, 10 May 2022 19:24:24 GMT, Mark Powers wrote:
>> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777:
>>
>>> 775: if (!printStackPropertiesSet && VM.initLevel() >= 1) {
>>> 776: printStackWhenAccessFails = GetBooleanAction.
>>> 777:
>>> privilegedGetProperty("sun.reflect.debugModuleAccessChecks");
>>
>> Running with `-Dsun.reflect.debugModuleAccessChecks` should set
>> printStackWhenAccessFails to true, not false.
>
> You are right. The old way maps the null string to true, and the new way maps
> it to false. I did not notice that. At this point, I see no value in making
> the "true".equals and "false".equals changes. Too much can break. I'll
> reverse these changes.
This change still needs to be reversed.
-
PR: https://git.openjdk.java.net/jdk/pull/8559
Re: RFR: 8287104: AddressChangeListener thread inherits CCL and can cause memory leak for webapp-servers
On Sun, 22 May 2022 08:20:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses > https://bugs.openjdk.java.net/browse/JDK-8287104? > > The change in this commit now uses an `InnocuousThread` to create a thread > with `null` context classloader. The `Runnable` task of this thread just > invokes a native method through JNI to be notified of IP addresses change of > the host. As such any specific thread context classloader isn't necessary in > this thread. > > Additionally, this commit does some minor changes like making the `lock` > member variable `final` and also marking the `changed` member variable as > `volatile`. These changes aren't necessary for this fix, but I think would be > good to have while we are changing this part of the code. > > Finally, the thread that we create here, now has a specific name > `Net-address-change-listener` instead of the usual system wide auto-generated > name. > > No new tests have been added for this change. Existing tier1, tier2 and tier3 > tests have been run and no related failures have been noticed. Thank you for the review Aleksei. What you suggest about the thread name makes sense. I have now updated the PR to use that name. - PR: https://git.openjdk.java.net/jdk/pull/8827
Re: RFR: 8287104: AddressChangeListener thread inherits CCL and can cause memory leak for webapp-servers [v2]
On Mon, 23 May 2022 12:27:39 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses >> https://bugs.openjdk.java.net/browse/JDK-8287104? >> >> The change in this commit now uses an `InnocuousThread` to create a thread >> with `null` context classloader. The `Runnable` task of this thread just >> invokes a native method through JNI to be notified of IP addresses change of >> the host. As such any specific thread context classloader isn't necessary in >> this thread. >> >> Additionally, this commit does some minor changes like making the `lock` >> member variable `final` and also marking the `changed` member variable as >> `volatile`. These changes aren't necessary for this fix, but I think would >> be good to have while we are changing this part of the code. >> >> Finally, the thread that we create here, now has a specific name >> `Net-address-change-listener` instead of the usual system wide >> auto-generated name. >> >> No new tests have been added for this change. Existing tier1, tier2 and >> tier3 tests have been run and no related failures have been noticed. > > Jaikiran Pai has updated the pull request incrementally with one additional > commit since the last revision: > > Aleksei's review suggestion - use a better Thread name Marked as reviewed by aefimov (Committer). - PR: https://git.openjdk.java.net/jdk/pull/8827
Re: RFR: 8287104: AddressChangeListener thread inherits CCL and can cause memory leak for webapp-servers [v2]
> Can I please get a review of this change which addresses > https://bugs.openjdk.java.net/browse/JDK-8287104? > > The change in this commit now uses an `InnocuousThread` to create a thread > with `null` context classloader. The `Runnable` task of this thread just > invokes a native method through JNI to be notified of IP addresses change of > the host. As such any specific thread context classloader isn't necessary in > this thread. > > Additionally, this commit does some minor changes like making the `lock` > member variable `final` and also marking the `changed` member variable as > `volatile`. These changes aren't necessary for this fix, but I think would be > good to have while we are changing this part of the code. > > Finally, the thread that we create here, now has a specific name > `Net-address-change-listener` instead of the usual system wide auto-generated > name. > > No new tests have been added for this change. Existing tier1, tier2 and tier3 > tests have been run and no related failures have been noticed. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Aleksei's review suggestion - use a better Thread name - Changes: - all: https://git.openjdk.java.net/jdk/pull/8827/files - new: https://git.openjdk.java.net/jdk/pull/8827/files/e4b71f6b..f1f4a7a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8827&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8827&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8827.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8827/head:pull/8827 PR: https://git.openjdk.java.net/jdk/pull/8827
Re: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on AIX [v7]
On Fri, 6 May 2022 09:18:33 GMT, Michael Felt wrote: >> Michael Felt has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Changes per review > > - Thx all for your assistance and patience. > - (Hoping you will consider this for backport as well). Hi @aixtools, This is just a reminder that you can proceed with the integration of this PR :) - PR: https://git.openjdk.java.net/jdk/pull/7013
Re: RFR: 8287104: AddressChangeListener thread inherits CCL and can cause memory leak for webapp-servers
On Sun, 22 May 2022 08:20:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses > https://bugs.openjdk.java.net/browse/JDK-8287104? > > The change in this commit now uses an `InnocuousThread` to create a thread > with `null` context classloader. The `Runnable` task of this thread just > invokes a native method through JNI to be notified of IP addresses change of > the host. As such any specific thread context classloader isn't necessary in > this thread. > > Additionally, this commit does some minor changes like making the `lock` > member variable `final` and also marking the `changed` member variable as > `volatile`. These changes aren't necessary for this fix, but I think would be > good to have while we are changing this part of the code. > > Finally, the thread that we create here, now has a specific name > `Net-address-change-listener` instead of the usual system wide auto-generated > name. > > No new tests have been added for this change. Existing tier1, tier2 and tier3 > tests have been run and no related failures have been noticed. Hi @jaikiran, Thanks for the fix. Chages look good to me with one suggestion: Could we reflect in a thread name the fact that it is JNDI/DNS specific one? Right now it is not clear - one might think that it could be related to `InetAddress`/`NetworkInterface` or other networking classes. Maybe something like `Jndi-Dns-address-change-listener`? - Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/8827
