Re: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
On Mon, 18 Jul 2022 23:27:58 GMT, David Holmes wrote: >> src/java.base/share/man/keytool.1 line 456: >> >>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >>> 455: keystore. >>> 456: This option is used to sign the certificate with the signer?s private >> >> Not a problem with this PR as such, but we still have a `?` character in the >> output. > > Yeah I spotted that too, but it would need to be fixed in source and nroff. > Must be some kind of "smart quote" from an editor. Do you think this needs to > be fixed or just handle it in mainline? Filed [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626). It can easily be fixed before RDP2. - PR: https://git.openjdk.org/jdk19/pull/145
[jdk19] Integrated: 8278274: Update nroff pages in JDK 19 before RC
On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes wrote: > Please review these changes to the nroff manpage files so that they match > their markdown sources that Oracle maintains. > > All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 > if needed. Additionally: > > The Java manpage was missing updates from: > - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to > tables on java man page. > > The Java manpage has slight formatting differences from: > - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath > separator: Man page says semicolon; should be colon on Linux > - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not > multiple of 4K does not work for the main thread on macOS > > The Java manpage has a typo fixed in mainline by > [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) > > > The keytool manpage was missing updates from: > - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to > tables on keytool man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger > default key sizes and algorithms based on CNSA > > The jar manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod > man pages need the new --date documenting from CSR > [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jarsigner manpage was missing updates from: > - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to > tables on jarsigner man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger > default key sizes and algorithms based on CNSA > > The javadoc manpage was missing updates from: > - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page > for javadoc `--date` option > > The jmod manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod > man pages need the new --date documenting from CSR > [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jpackage manpage was missing updates from: > - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document > jpackage resource dir feature > - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage > man pages for JDK 19 > - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace > remaining usages of 'a the' in source code > > The jshell manpage was missing updates from: > - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to > tables on jshell man page. This pull request has now been integrated. Changeset: 618f3a82 Author:David Holmes URL: https://git.openjdk.org/jdk19/commit/618f3a82a4d45cdb66b86259ae60dd1c322b987b Stats: 515 lines in 28 files changed: 431 ins; 16 del; 68 mod 8278274: Update nroff pages in JDK 19 before RC Reviewed-by: jjg - PR: https://git.openjdk.org/jdk19/pull/145
Re: RFR: 8290504: Close streams returned by ModuleReader::list
On Tue, 19 Jul 2022 14:07:17 GMT, Ryan Ernst wrote: > This commit ensures streams returned by ModuleReader::list are closed. Hello Ryan, the failures reported in the GitHub Actions jobs look related to this change. One such failure is in `CallerSensitiveAccess` test which throws an exception as follows: java.lang.RuntimeException: java.lang.IllegalStateException: source already consumed or closed at org.testng.internal.MethodInvocationHelper.invokeMethodNoCheckedException(MethodInvocationHelper.java:49) at org.testng.internal.MethodInvocationHelper.invokeDataProvider(MethodInvocationHelper.java:145) at org.testng.internal.Parameters.handleParameters(Parameters.java:797) at org.testng.internal.Parameters.handleParameters(Parameters.java:740) at org.testng.internal.ParameterHandler.handleParameters(ParameterHandler.java:59) at org.testng.internal.ParameterHandler.createParameters(ParameterHandler.java:38) at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:789) at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at org.testng.TestRunner.privateRun(TestRunner.java:764) at org.testng.TestRunner.run(TestRunner.java:585) at org.testng.SuiteRunner.runTest(SuiteRunner.java:384) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337) at org.testng.SuiteRunner.run(SuiteRunner.java:286) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218) at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) at org.testng.TestNG.runSuites(TestNG.java:1069) at org.testng.TestNG.run(TestNG.java:1037) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:1589) Caused by: java.lang.IllegalStateException: source already consumed or closed at java.base/java.util.stream.AbstractPipeline.sourceSpliterator(AbstractPipeline.java:409) at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) at CallerSensitiveAccess.callerSensitiveMethods(CallerSensitiveAccess.java:67) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:76) at org.testng.internal.MethodInvocationHelper.invokeMethodNoCheckedException(MethodInvocationHelper.java:45) ... 28 more - Changes requested by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/9557
Re: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v3]
On Tue, 19 Jul 2022 14:06:52 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst 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 five additional commits since > the last revision: > > - Merge branch 'master' into try_files/module_reader > - Revert "fix uses of list() in java.base" > >This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. > - adjust wording > - fix uses of list() in java.base > - 8290353: Clarify the streams returned by ModuleReader::list > >This commit adds additional clarification to the javadocs of >ModuleReader::list about needing to close the stream. The new wording is >similar to that used in Files::find and other similar methods. Hello Ryan, the change looks fine to me. Please update the copyright year on the ModuleReader.java file, from 2020 to 2022. - PR: https://git.openjdk.org/jdk/pull/9538
Re: RFR: 8290504: Close streams returned by ModuleReader::list
On Tue, 19 Jul 2022 14:07:17 GMT, Ryan Ernst wrote: > This commit ensures streams returned by ModuleReader::list are closed. LGTM - Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/9557
Re: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v3]
On Tue, 19 Jul 2022 14:06:52 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst 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 five additional commits since > the last revision: > > - Merge branch 'master' into try_files/module_reader > - Revert "fix uses of list() in java.base" > >This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. > - adjust wording > - fix uses of list() in java.base > - 8290353: Clarify the streams returned by ModuleReader::list > >This commit adds additional clarification to the javadocs of >ModuleReader::list about needing to close the stream. The new wording is >similar to that used in Files::find and other similar methods. Ship it! - Marked as reviewed by mr (Lead). PR: https://git.openjdk.org/jdk/pull/9538
Integrated: 8290398: jpackage exe installers are not installed in jtreg tests
On Sat, 16 Jul 2022 21:22:46 GMT, Alexey Semenyuk wrote: > 8290398: jpackage exe installers are not installed in jtreg tests This pull request has now been integrated. Changeset: c2cbeb3e Author:Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/c2cbeb3ee875936c98bb15ec32d692f7d866df76 Stats: 56 lines in 1 file changed: 35 ins; 0 del; 21 mod 8290398: jpackage exe installers are not installed in jtreg tests Reviewed-by: almatvee - PR: https://git.openjdk.org/jdk/pull/9530
Integrated: 8290400: Must run exe installers in jpackage jtreg tests without UI
On Sat, 16 Jul 2022 21:32:07 GMT, Alexey Semenyuk wrote: > 8290400: Must run exe installers in jpackage jtreg tests without UI This pull request has now been integrated. Changeset: 1af7c33d Author:Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/1af7c33df59cd043bdae3f681aeded2919dc27aa Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8290400: Must run exe installers in jpackage jtreg tests without UI Reviewed-by: almatvee - PR: https://git.openjdk.org/jdk/pull/9531
Integrated: 8283707: Support version format on Windows
On Fri, 15 Jul 2022 04:37:58 GMT, Alexey Semenyuk wrote: > 8283707: Support version format on Windows This pull request has now been integrated. Changeset: 977e0948 Author:Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/977e09489dd1f49d8f373ef7b8c5e47fedb82793 Stats: 1316 lines in 15 files changed: 1256 ins; 18 del; 42 mod 8283707: Support version format on Windows Reviewed-by: almatvee - PR: https://git.openjdk.org/jdk/pull/9507
Integrated: 8290402: jpackage exe uninstallers don't return correct exit code in case of failure
On Sat, 16 Jul 2022 21:47:43 GMT, Alexey Semenyuk wrote: > 8290402: jpackage exe uninstallers don't return correct exit code in case of > failure This pull request has now been integrated. Changeset: d67e7ccd Author:Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/d67e7ccda56998d1d60bdaa4e5940a0c501ead23 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8290402: jpackage exe uninstallers don't return correct exit code in case of failure Reviewed-by: almatvee - PR: https://git.openjdk.org/jdk/pull/9532
RFR: Merge jdk19
Forwardport JDK 19 -> JDK 20 - Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8290524: Typo in javadoc of MemorySegment/MemoryAddress - 8288482: JFR: Cannot resolve method - 8290417: CDS cannot archive lamda proxy with useImplMethodHandle The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk=9561=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk=9561=00.1 Changes: https://git.openjdk.org/jdk/pull/9561/files Stats: 510 lines in 10 files changed: 437 ins; 0 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/9561.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9561/head:pull/9561 PR: https://git.openjdk.org/jdk/pull/9561
Integrated: 8290391: Reduce runtime of java.util package microbenchmarks
On Fri, 15 Jul 2022 18:41:09 GMT, Eric Caspole wrote: > Adds Warmup, Measurement and Fork annotations to reduce the run time from 1 > day 16 hours to 8 hours for this set. This pull request has now been integrated. Changeset: 2cb659e7 Author:Eric Caspole URL: https://git.openjdk.org/jdk/commit/2cb659e7f45e5ed4c2db7f1a091bb78f4f7accc2 Stats: 175 lines in 16 files changed: 71 ins; 85 del; 19 mod 8290391: Reduce runtime of java.util package microbenchmarks Reviewed-by: rriggs, redestad - PR: https://git.openjdk.org/jdk/pull/9523
Re: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v3]
On Tue, 19 Jul 2022 14:06:52 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst 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 five additional commits since > the last revision: > > - Merge branch 'master' into try_files/module_reader > - Revert "fix uses of list() in java.base" > >This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. > - adjust wording > - fix uses of list() in java.base > - 8290353: Clarify the streams returned by ModuleReader::list > >This commit adds additional clarification to the javadocs of >ModuleReader::list about needing to close the stream. The new wording is >similar to that used in Files::find and other similar methods. Marked as reviewed by mchung (Reviewer). Looks good to me. I reviewed the CSR. - PR: https://git.openjdk.org/jdk/pull/9538
Re: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v3]
On Tue, 19 Jul 2022 14:06:52 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst 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 five additional commits since > the last revision: > > - Merge branch 'master' into try_files/module_reader > - Revert "fix uses of list() in java.base" > >This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. > - adjust wording > - fix uses of list() in java.base > - 8290353: Clarify the streams returned by ModuleReader::list > >This commit adds additional clarification to the javadocs of >ModuleReader::list about needing to close the stream. The new wording is >similar to that used in Files::find and other similar methods. LGTM - Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/9538
[jdk19] Integrated: 8290524: Typo in javadoc of MemorySegment/MemoryAddress
On Tue, 19 Jul 2022 11:07:27 GMT, Maurizio Cimadamore wrote: > This patch fixes several `toRowLongValue` instead of `toRawLongValue` > scattered in the javadoc for accessor methods in `MemorySegment` and > `MemoryAddress`. This pull request has now been integrated. Changeset: e062dff1 Author:Maurizio Cimadamore URL: https://git.openjdk.org/jdk19/commit/e062dff1bfd1abd5f14e8915dc5417cc22d622ac Stats: 69 lines in 2 files changed: 0 ins; 0 del; 69 mod 8290524: Typo in javadoc of MemorySegment/MemoryAddress Reviewed-by: jvernee - PR: https://git.openjdk.org/jdk19/pull/148
Re: [jdk19] RFR: 8290524: Typo in javadoc of MemorySegment/MemoryAddress
On Tue, 19 Jul 2022 11:07:27 GMT, Maurizio Cimadamore wrote: > This patch fixes several `toRowLongValue` instead of `toRawLongValue` > scattered in the javadoc for accessor methods in `MemorySegment` and > `MemoryAddress`. Marked as reviewed by jvernee (Reviewer). - PR: https://git.openjdk.org/jdk19/pull/148
Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3]
On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more >> resilient on some of the stranger systems. Unfortunately, I wasn't able to >> re-create a similar system as the reporter. The idea of using the longest >> substring match for the cgroupv1 file paths was based on the fact that on >> systemd systems processes run in separate scopes and the maven forked test >> runner might exhibit this property. For that it makes sense to use the >> common ancestor path. Nothing changes in the common cases where the >> `cgroup_path` matches `_root` and when the `_root` is `/` (container the >> former, host system the latter). >> >> In addition, the code paths which are susceptible to throw NPE have been >> hardened to catch those situations. Should it happen in the future it makes >> more sense (to me) to not have accurate container detection in favor of >> continuing to keep running. >> >> Finally, with the added unit-tests a bug was uncovered on the "substring" >> match case of cgroup paths in hotspot. `p` returned from `strstr` can never >> point to `_root` as it's used as the "needle" to find in "haystack" >> `cgroup_path` (not the other way round). >> >> Testing: >> - [x] Added unit tests >> - [x] GHA >> - [x] Container tests on cgroups v1 Linux. Continue to pass > > Severin Gehwolf has updated the pull request incrementally with two > additional commits since the last revision: > > - Refactor hotspot gtest > - Separate into function. Fix comment. It's still on my plate to work on, but priorities keep this pushed to the bottom... - PR: https://git.openjdk.org/jdk/pull/8629
Re: RFR: 8290504: Close streams returned by ModuleReader::list
On Tue, 19 Jul 2022 14:07:17 GMT, Ryan Ernst wrote: > This commit ensures streams returned by ModuleReader::list are closed. Note that ModulePatcher::list delegates to ModuleReader::list, but since the stream it builds closes the underlying stream, the use doesn't need to be closed within the list method. - PR: https://git.openjdk.org/jdk/pull/9557
RFR: 8290504: Close streams returned by ModuleReader::list
This commit ensures streams returned by ModuleReader::list are closed. - Commit messages: - 8290504: Close streams returned by ModuleReader::list Changes: https://git.openjdk.org/jdk/pull/9557/files Webrev: https://webrevs.openjdk.org/?repo=jdk=9557=00 Issue: https://bugs.openjdk.org/browse/JDK-8290504 Stats: 19 lines in 5 files changed: 10 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9557.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9557/head:pull/9557 PR: https://git.openjdk.org/jdk/pull/9557
Re: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v3]
> This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Ryan Ernst 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 five additional commits since the last revision: - Merge branch 'master' into try_files/module_reader - Revert "fix uses of list() in java.base" This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. - adjust wording - fix uses of list() in java.base - 8290353: Clarify the streams returned by ModuleReader::list This commit adds additional clarification to the javadocs of ModuleReader::list about needing to close the stream. The new wording is similar to that used in Files::find and other similar methods. - Changes: - all: https://git.openjdk.org/jdk/pull/9538/files - new: https://git.openjdk.org/jdk/pull/9538/files/0b3ca182..181c47a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=9538=02 - incr: https://webrevs.openjdk.org/?repo=jdk=9538=01-02 Stats: 1282 lines in 88 files changed: 948 ins; 133 del; 201 mod Patch: https://git.openjdk.org/jdk/pull/9538.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9538/head:pull/9538 PR: https://git.openjdk.org/jdk/pull/9538
RFR: 8290531: Loom: Parallelize a few tests more deeply
Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: # release before real 4m41.424s user 24m18.064s sys 1m16.440s # release after real 2m47.769s ; -40% user 23m44.622s sys 1m15.240s # fastdebug before real 5m38.078s user 67m23.516s sys 1m56.446s # fastdebug after real 4m9.249s; -26% user 67m21.940s sys 1m57.625s - Commit messages: - More fixes - Fix Changes: https://git.openjdk.org/jdk/pull/9554/files Webrev: https://webrevs.openjdk.org/?repo=jdk=9554=00 Issue: https://bugs.openjdk.org/browse/JDK-8290531 Stats: 34 lines in 2 files changed: 19 ins; 3 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9554.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9554/head:pull/9554 PR: https://git.openjdk.org/jdk/pull/9554
Integrated: 8290397: LoadLibraryUnload.java failed with "Too few cleared WeakReferences"
On Mon, 18 Jul 2022 22:31:13 GMT, Roger Riggs wrote: > When running with -Xcomp it seems the wait time for GC to clear references > is insufficient. > Extend timeout waiting for GC. This pull request has now been integrated. Changeset: e02627ca Author:Roger Riggs URL: https://git.openjdk.org/jdk/commit/e02627ca0a3381b3a52a71aef41ce5ba3329142b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8290397: LoadLibraryUnload.java failed with "Too few cleared WeakReferences" Reviewed-by: mchung - PR: https://git.openjdk.org/jdk/pull/9545
[jdk19] RFR: 8290524: Typo in javadoc of MemorySegment/MemoryAddress
This patch fixes several `toRowLongValue` instead of `toRawLongValue` scattered in the javadoc for accessor methods in `MemorySegment` and `MemoryAddress`. - Commit messages: - Fix MemoryAddress typos - Initial push Changes: https://git.openjdk.org/jdk19/pull/148/files Webrev: https://webrevs.openjdk.org/?repo=jdk19=148=00 Issue: https://bugs.openjdk.org/browse/JDK-8290524 Stats: 69 lines in 2 files changed: 0 ins; 0 del; 69 mod Patch: https://git.openjdk.org/jdk19/pull/148.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/148/head:pull/148 PR: https://git.openjdk.org/jdk19/pull/148
Re: RFR: 8290471: jpackage: allow to specify codepage on Windows
On Mon, 18 Jul 2022 22:33:15 GMT, Alex Kasko wrote: > It is proposed to introduce support for `--win-codepage` argument, and > substitute the `Codepage` attribute with `--win-codepage` specified value in > primary l10n file when it is being copied to the config dir. > > Instead of copying all internal l10n files, it is proposed to copy only the > primary file. Plain copy is used if `--win-codepage` is not specified. > Otherwise `--win-codepage` value is substituted in l10n file using DOM and > XPath. > > See more details in issue description and in links added there. > > Testing: > > - [x] ran `jtreg:jdk/tools/jpackage` > - [x] test for `--win-codepage` argument is included with the patch Thanks for the example link! I've filed CSR based on it - [JDK-8290519](https://bugs.openjdk.org/browse/JDK-8290519). - PR: https://git.openjdk.org/jdk/pull/9546
Re: RFR: 8290353: Clarify the streams returned by ModuleReader::list [v2]
On Mon, 18 Jul 2022 18:19:48 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst has updated the pull request incrementally with two additional > commits since the last revision: > > - adjust wording > - fix uses of list() in java.base The following CSR has been filed for this issue, https://bugs.openjdk.org/browse/JDK-8290521. Please review. - PR: https://git.openjdk.org/jdk/pull/9538
Re: RFR: 8290353: Clarify the streams returned by ModuleReader::list [v2]
On Mon, 18 Jul 2022 19:48:02 GMT, Mark Reinhold wrote: > It’s odd to mix adding some advice to the Javadoc with adopting that advice > in the code base. Consider opening a new issue and PR for the actual code > changes. [JDK-8290504][1] has been filed to track the implementation changes. @rjernst please separate out the implementation changes into a separate PR, using 8290504 as the linked JIRA issue. (apologies, I previously asked for the implementation changes to be in this PR ) > Also, a better summary for this issue (and PR) would be “ModuleReader::list > specification should suggest closing the returned stream,” since that’s the > essence of it. Agreed. I updated the JIRA issue summary as suggested. @rjernst please update the title of this PR to match. [1]: https://bugs.openjdk.org/browse/JDK-8290504 - PR: https://git.openjdk.org/jdk/pull/9538
Re: [jdk19] RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs
On Mon, 18 Jul 2022 14:48:42 GMT, Roger Riggs wrote: > Committing to the mainline and then requesting a backport of the changeset > works too. Yes, that would be my plan. - PR: https://git.openjdk.org/jdk19/pull/27
Integrated: JDK-8290460: Alpine: disable some panama tests that rely on std::thread
On Mon, 18 Jul 2022 14:21:19 GMT, Thomas Stuefe wrote: > Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved, > I'd like to disable > > - java/foreign/TestUpcallAsync.java > - java/foreign/enablenativeaccess/TestEnableNativeAccess.java > > on muslc to take load from our CIs. > > Tests: tested locally that the tests are excluded on Alpine, and remain > active on other platforms. This pull request has now been integrated. Changeset: d7f0de27 Author:Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69d7 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod 8290460: Alpine: disable some panama tests that rely on std::thread Reviewed-by: jvernee, dholmes - PR: https://git.openjdk.org/jdk/pull/9539
Re: RFR: JDK-8290460: Alpine: disable some panama tests that rely on std::thread
On Mon, 18 Jul 2022 22:21:44 GMT, Jorn Vernee wrote: >> Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved, >> I'd like to disable >> >> - java/foreign/TestUpcallAsync.java >> - java/foreign/enablenativeaccess/TestEnableNativeAccess.java >> >> on muslc to take load from our CIs. >> >> Tests: tested locally that the tests are excluded on Alpine, and remain >> active on other platforms. > > LGTM. Thanks @JornVernee and @dholmes-ora ! - PR: https://git.openjdk.org/jdk/pull/9539
Re: RFR: 8290359: Ensure that all directory streams are closed in jdk.link [v2]
On Mon, 18 Jul 2022 18:22:02 GMT, Ryan Ernst wrote: >> This commit adds try-with-resources for uses of Stream from Files >> methods that walk directories. > > Ryan Ernst 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 three additional commits since > the last revision: > > - Merge branch 'master' into try_files/jdk.link > - fix alignment > - 8290359: Ensure that all directory streams are closed in jdk.link > >This commit adds try-with-resources for uses of Stream from Files >methods that walk directories. LGTM - Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/9520
Re: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows enviromnent
On Fri, 8 Jul 2022 12:10:29 GMT, Jaikiran Pai wrote:
>> I removed a section of via JDK_JAVA_OPTIONS because including main class is
>> not allowed in the specification.
>> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment
>> variable. At this time, this test is mismatch with the specification.
>> I tried to test and get Passed on Japanese Windows environment.
>> Could you review this fix, please?
>
> The change looks fine to me since in its current form the usage of
> `JDK_JAVA_OPTIONS` is incorrect.
>
> Having said that and looking at the history of this file, I think, this part
> of the test was added to check if the `java` launcher would be able to read
> an environment variable (specifically the `JDK_JAVA_OPTIONS`) whose value was
> in `MS932` encoding, and pass it along as a correctly encoded String, all the
> way to the main method of the application. If we remove this section of the
> test, then we would be skipping that code path completely.
>
> Perhaps this part of the test could be modified a bit to let it pass the
> `JDK_JAVA_OPTIONS` environment variable with a `MS932` encoded value that
> acts some option to the java launcher, instead of being the argument to the
> main method? That way, you won't have to specify the main class name in the
> value of the environment variable. Specifically, something like:
>
>
> diff --git a/test/jdk/tools/launcher/I18NArgTest.java
> b/test/jdk/tools/launcher/I18NArgTest.java
> index fa09736da2f..2ba724d6f1d 100644
> --- a/test/jdk/tools/launcher/I18NArgTest.java
> +++ b/test/jdk/tools/launcher/I18NArgTest.java
> @@ -97,12 +97,17 @@ public class I18NArgTest extends TestHelper {
>
> // Test via JDK_JAVA_OPTIONS
> Map env = new HashMap<>();
> -String cmd = "-Dtest.src=" + TEST_SOURCES_DIR.getAbsolutePath() +
> -" -Dtest.classes=" + TEST_CLASSES_DIR.getAbsolutePath() +
> -" -cp " + TEST_CLASSES_DIR.getAbsolutePath() +
> -" I18NArgTest " + unicodeStr + " " + hexValue;
> -env.put("JDK_JAVA_OPTIONS", cmd);
> -tr = doExec(env, javaCmd);
> +String sysPropName = "foo.bar";
> +// pass "-Dfoo.bar=" through the JDK_JAVA_OPTIONS
> environment variable.
> +// we expect that system property value to be passed along to the
> main method with the
> +// correct encoding
> +String jdkJavaOpts = "-D" + sysPropName + "=" + unicodeStr;
> +env.put("JDK_JAVA_OPTIONS", jdkJavaOpts);
> +tr = doExec(env,javaCmd,
> +"-Dtest.src=" + TEST_SOURCES_DIR.getAbsolutePath(),
> +"-Dtest.classes=" + TEST_CLASSES_DIR.getAbsolutePath(),
> +"-cp", TEST_CLASSES_DIR.getAbsolutePath(),
> +"I18NArgTest", unicodeStr, hexValue, sysPropName);
> System.out.println(tr.testOutput);
> if (!tr.isOK()) {
> System.err.println(tr);
> @@ -125,5 +130,23 @@ public class I18NArgTest extends TestHelper {
> "expected:" + expected + " obtained:" + hexValue;
> throw new RuntimeException(message);
> }
> +if (args.length == 3) {
> +// verify the value of the system property matches the expected
> value
> +String sysPropName = args[2];
> +String sysPropVal = System.getProperty(sysPropName);
> +if (sysPropVal == null) {
> +throw new RuntimeException("Missing system property " +
> sysPropName);
> +}
> +String sysPropHexVal = "";
> +for (int i = 0; i < sysPropVal.length(); i++) {
> +sysPropHexVal =
> sysPropHexVal.concat(Integer.toHexString(sysPropVal.charAt(i)));
> +}
> +System.out.println("System property " + sysPropName + " computed
> hex value: "
> ++ sysPropHexVal);
> +if (!sysPropHexVal.equals(expected)) {
> +throw new RuntimeException("Unexpected value in system
> property, expected "
> ++ expected + ", but got " + sysPropHexVal);
> +}
> +}
> }
> }
>
> I haven't tested this change, so you might have to experiment with it a bit.
> What do you think?
@jaikiran
Thank you for your comment. I agree to the additional check.
I run the test you proposed, but it failed. I'm surveying that reason.
-
PR: https://git.openjdk.org/jdk/pull/9389
Re: RFR: JDK-8290460: Alpine: disable some panama tests that rely on std::thread
On Mon, 18 Jul 2022 14:21:19 GMT, Thomas Stuefe wrote: > Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved, > I'd like to disable > > - java/foreign/TestUpcallAsync.java > - java/foreign/enablenativeaccess/TestEnableNativeAccess.java > > on muslc to take load from our CIs. > > Tests: tested locally that the tests are excluded on Alpine, and remain > active on other platforms. Marked as reviewed by dholmes (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9539
