From shade at openjdk.java.net Mon Aug 2 10:33:44 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 2 Aug 2021 10:33:44 GMT Subject: RFR: 8271605: Update JMH devkit to 1.32 Message-ID: It is currently at 1.28, and thus misses a bunch of fixes and improvements. 1.32 is the latest version, and probably the last version before enabling the automatic detection of compiler blackholes (CODETOOLS-7903004), the change that would affect benchmarks performance. ------------- Commit messages: - 8271605: Update JMH devkit to 1.32 Changes: https://git.openjdk.java.net/jdk/pull/4954/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4954&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271605 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4954.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4954/head:pull/4954 PR: https://git.openjdk.java.net/jdk/pull/4954 From redestad at openjdk.java.net Mon Aug 2 10:45:30 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 10:45:30 GMT Subject: RFR: 8271605: Update JMH devkit to 1.32 In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 10:27:08 GMT, Aleksey Shipilev wrote: > It is currently at 1.28, and thus misses a bunch of fixes and improvements. 1.32 is the latest version, and probably the last version before enabling the automatic detection of compiler blackholes (CODETOOLS-7903004), the change that would affect benchmarks performance. Looks good to me. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4954 From ecaspole at openjdk.java.net Mon Aug 2 13:58:32 2021 From: ecaspole at openjdk.java.net (Eric Caspole) Date: Mon, 2 Aug 2021 13:58:32 GMT Subject: RFR: 8271605: Update JMH devkit to 1.32 In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 10:27:08 GMT, Aleksey Shipilev wrote: > It is currently at 1.28, and thus misses a bunch of fixes and improvements. 1.32 is the latest version, and probably the last version before enabling the automatic detection of compiler blackholes (CODETOOLS-7903004), the change that would affect benchmarks performance. Looks good. Thanks. ------------- Marked as reviewed by ecaspole (Committer). PR: https://git.openjdk.java.net/jdk/pull/4954 From shade at openjdk.java.net Mon Aug 2 15:09:35 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 2 Aug 2021 15:09:35 GMT Subject: RFR: 8271605: Update JMH devkit to 1.32 In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 10:27:08 GMT, Aleksey Shipilev wrote: > It is currently at 1.28, and thus misses a bunch of fixes and improvements. 1.32 is the latest version, and probably the last version before enabling the automatic detection of compiler blackholes (CODETOOLS-7903004), the change that would affect benchmarks performance. Thanks! (and welcome back, Claes) ------------- PR: https://git.openjdk.java.net/jdk/pull/4954 From shade at openjdk.java.net Mon Aug 2 15:09:35 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 2 Aug 2021 15:09:35 GMT Subject: Integrated: 8271605: Update JMH devkit to 1.32 In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 10:27:08 GMT, Aleksey Shipilev wrote: > It is currently at 1.28, and thus misses a bunch of fixes and improvements. 1.32 is the latest version, and probably the last version before enabling the automatic detection of compiler blackholes (CODETOOLS-7903004), the change that would affect benchmarks performance. This pull request has now been integrated. Changeset: e74537f9 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/e74537f9241e57b4668ff542364220936e920330 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8271605: Update JMH devkit to 1.32 Reviewed-by: redestad, ecaspole ------------- PR: https://git.openjdk.java.net/jdk/pull/4954 From mikael at openjdk.java.net Mon Aug 2 18:45:54 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 2 Aug 2021 18:45:54 GMT Subject: [jdk17] RFR: 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 06:47:07 GMT, Saravana Kumar Vijayasekaran wrote: > 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/297 From svijayasekar at openjdk.java.net Mon Aug 2 18:45:55 2021 From: svijayasekar at openjdk.java.net (Saravana Kumar Vijayasekaran) Date: Mon, 2 Aug 2021 18:45:55 GMT Subject: [jdk17] Integrated: 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 06:47:07 GMT, Saravana Kumar Vijayasekaran wrote: > 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) This pull request has now been integrated. Changeset: f8fb5713 Author: Saravana Kumar Vijayasekaran Committer: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk17/commit/f8fb5713074b8960f5530d7aca954f84d57c1f30 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) Reviewed-by: iris, mikael ------------- PR: https://git.openjdk.java.net/jdk17/pull/297 From jwilhelm at openjdk.java.net Mon Aug 2 23:38:00 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 2 Aug 2021 23:38:00 GMT Subject: RFR: Merge jdk17 Message-ID: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8067223: [TESTBUG] Rename Whitebox API package - 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4964&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4964&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4964/files Stats: 535 lines in 37 files changed: 449 ins; 1 del; 85 mod Patch: https://git.openjdk.java.net/jdk/pull/4964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4964/head:pull/4964 PR: https://git.openjdk.java.net/jdk/pull/4964 From jwilhelm at openjdk.java.net Mon Aug 2 23:53:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 2 Aug 2021 23:53:59 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> References: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Revert "8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34)" This reverts commit f8fb5713074b8960f5530d7aca954f84d57c1f30. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4964/files - new: https://git.openjdk.java.net/jdk/pull/4964/files/a95b06a1..e353ddcc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4964&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4964&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4964/head:pull/4964 PR: https://git.openjdk.java.net/jdk/pull/4964 From mikael at openjdk.java.net Tue Aug 3 00:01:33 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 3 Aug 2021 00:01:33 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> Message-ID: <8IbQAIkLr13OmKSOcnZrb5FRd6tN-pdqAAJlHnIbh-8=.cbb12df6-21d6-42c4-b9f4-82db2dadc9b4@github.com> On Mon, 2 Aug 2021 23:53:59 GMT, Jesper Wilhelmsson wrote: >> Forwardport JDK 17 -> JDK 18 > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Revert "8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34)" > > This reverts commit f8fb5713074b8960f5530d7aca954f84d57c1f30. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4964 From jwilhelm at openjdk.java.net Tue Aug 3 01:04:35 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 3 Aug 2021 01:04:35 GMT Subject: Integrated: Merge jdk17 In-Reply-To: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> References: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> Message-ID: On Mon, 2 Aug 2021 23:30:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: c8add223 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/c8add223a10030e40ccef42e081fd0d8f00e0593 Stats: 534 lines in 36 files changed: 449 ins; 1 del; 84 mod Merge Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/4964 From iignatyev at openjdk.java.net Tue Aug 3 20:21:38 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 3 Aug 2021 20:21:38 GMT Subject: [jdk17] Withdrawn: 8269037: jsig/Testjsig.java doesn't have to be restricted to linux only In-Reply-To: References: Message-ID: On Sun, 20 Jun 2021 11:08:21 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that enables `runtime/jsig/Testjsig.java` test and compilation of its native library on all platforms but windows? > from JBS: >> `runtime/jsig/Testjsig.java` test currently `@requires (os.family == "linux")` and `test/hotspot/jtreg/runtime/jsig/libTestJNI.c` compilation is resticted to linux only, howere there seems to be nothing in the test code that prevents it from execution on a system that supports POSIX. > > testing: `runtime/jsig/Testjsig.java` on `{linux,windows,macosx}-x64` > > > Thanks, > -- Igor This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk17/pull/105 From iignatyev at openjdk.java.net Tue Aug 3 20:21:38 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 3 Aug 2021 20:21:38 GMT Subject: [jdk17] RFR: 8269037: jsig/Testjsig.java doesn't have to be restricted to linux only In-Reply-To: References: Message-ID: On Sun, 20 Jun 2021 11:08:21 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that enables `runtime/jsig/Testjsig.java` test and compilation of its native library on all platforms but windows? > from JBS: >> `runtime/jsig/Testjsig.java` test currently `@requires (os.family == "linux")` and `test/hotspot/jtreg/runtime/jsig/libTestJNI.c` compilation is resticted to linux only, howere there seems to be nothing in the test code that prevents it from execution on a system that supports POSIX. > > testing: `runtime/jsig/Testjsig.java` on `{linux,windows,macosx}-x64` > > > Thanks, > -- Igor closed in favor of openjdk/jdk#4975 ------------- PR: https://git.openjdk.java.net/jdk17/pull/105 From iignatyev at openjdk.java.net Tue Aug 3 20:25:43 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 3 Aug 2021 20:25:43 GMT Subject: RFR: 8269037: jsig/Testjsig.java doesn't have to be restricted to linux only Message-ID: Hi all, could you please review this small patch that enables `runtime/jsig/Testjsig.java` test and compilation of its native library on all platforms but windows? from JBS: > `runtime/jsig/Testjsig.java` test currently `@requires (os.family == "linux")` and `test/hotspot/jtreg/runtime/jsig/libTestJNI.c` compilation is restricted to linux only, however there seems to be nothing in the test code that prevents it from execution on a system that supports POSIX. testing: `runtime/jsig/Testjsig.java` on `{linux,windows,macosx}-x64` Thanks, -- Igor ------------- Commit messages: - 8269037 Changes: https://git.openjdk.java.net/jdk/pull/4975/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4975&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269037 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4975.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4975/head:pull/4975 PR: https://git.openjdk.java.net/jdk/pull/4975 From mseledtsov at openjdk.java.net Tue Aug 3 20:31:29 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 3 Aug 2021 20:31:29 GMT Subject: RFR: 8269037: jsig/Testjsig.java doesn't have to be restricted to linux only In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 20:18:11 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that enables `runtime/jsig/Testjsig.java` test and compilation of its native library on all platforms but windows? > from JBS: >> `runtime/jsig/Testjsig.java` test currently `@requires (os.family == "linux")` and `test/hotspot/jtreg/runtime/jsig/libTestJNI.c` compilation is restricted to linux only, however there seems to be nothing in the test code that prevents it from execution on a system that supports POSIX. > > testing: `runtime/jsig/Testjsig.java` on `{linux,windows,macosx}-x64` > > Thanks, > -- Igor Changes look good to me. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk/pull/4975 From iignatyev at openjdk.java.net Wed Aug 4 02:21:39 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 4 Aug 2021 02:21:39 GMT Subject: RFR: 8269037: jsig/Testjsig.java doesn't have to be restricted to linux only In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 20:18:11 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that enables `runtime/jsig/Testjsig.java` test and compilation of its native library on all platforms but windows? > from JBS: >> `runtime/jsig/Testjsig.java` test currently `@requires (os.family == "linux")` and `test/hotspot/jtreg/runtime/jsig/libTestJNI.c` compilation is restricted to linux only, however there seems to be nothing in the test code that prevents it from execution on a system that supports POSIX. > > testing: `runtime/jsig/Testjsig.java` on `{linux,windows,macosx}-x64` > > Thanks, > -- Igor David, Misha, thank you for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/4975 From dholmes at openjdk.java.net Wed Aug 4 02:21:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 Aug 2021 02:21:39 GMT Subject: RFR: 8269037: jsig/Testjsig.java doesn't have to be restricted to linux only In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 20:18:11 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that enables `runtime/jsig/Testjsig.java` test and compilation of its native library on all platforms but windows? > from JBS: >> `runtime/jsig/Testjsig.java` test currently `@requires (os.family == "linux")` and `test/hotspot/jtreg/runtime/jsig/libTestJNI.c` compilation is restricted to linux only, however there seems to be nothing in the test code that prevents it from execution on a system that supports POSIX. > > testing: `runtime/jsig/Testjsig.java` on `{linux,windows,macosx}-x64` > > Thanks, > -- Igor Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4975 From iignatyev at openjdk.java.net Wed Aug 4 02:21:40 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 4 Aug 2021 02:21:40 GMT Subject: Integrated: 8269037: jsig/Testjsig.java doesn't have to be restricted to linux only In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 20:18:11 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that enables `runtime/jsig/Testjsig.java` test and compilation of its native library on all platforms but windows? > from JBS: >> `runtime/jsig/Testjsig.java` test currently `@requires (os.family == "linux")` and `test/hotspot/jtreg/runtime/jsig/libTestJNI.c` compilation is restricted to linux only, however there seems to be nothing in the test code that prevents it from execution on a system that supports POSIX. > > testing: `runtime/jsig/Testjsig.java` on `{linux,windows,macosx}-x64` > > Thanks, > -- Igor This pull request has now been integrated. Changeset: 34ba70a7 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/34ba70a71ba414a6d8cfc5c667d556d4d6072793 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8269037: jsig/Testjsig.java doesn't have to be restricted to linux only Reviewed-by: mseledtsov, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/4975 From redestad at openjdk.java.net Wed Aug 4 07:33:33 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 4 Aug 2021 07:33:33 GMT Subject: RFR: 8271605: Update JMH devkit to 1.32 In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 15:04:18 GMT, Aleksey Shipilev wrote: > Thanks! (and welcome back, Claes) You're welcome - and thanks! Good to be back.. ------------- PR: https://git.openjdk.java.net/jdk/pull/4954 From dholmes at openjdk.java.net Fri Aug 6 02:04:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 Aug 2021 02:04:42 GMT Subject: RFR: 8272067: Initial nroff manpage generation for JDK 18 Message-ID: Please review this trivial update to the generated manpages that updates their version from "JDK 17" to "JDK 18-ea". Thanks, David ------------- Commit messages: - 8272067: Initial nroff manpage generation for JDK 18 Changes: https://git.openjdk.java.net/jdk/pull/5028/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5028&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272067 Stats: 26 lines in 26 files changed: 0 ins; 0 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/5028.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5028/head:pull/5028 PR: https://git.openjdk.java.net/jdk/pull/5028 From darcy at openjdk.java.net Fri Aug 6 03:09:29 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 6 Aug 2021 03:09:29 GMT Subject: RFR: 8272067: Initial nroff manpage generation for JDK 18 In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 01:53:51 GMT, David Holmes wrote: > Please review this trivial update to the generated manpages that updates their version from "JDK 17" to "JDK 18-ea". > > Thanks, > David Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5028 From dholmes at openjdk.java.net Fri Aug 6 03:52:29 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 Aug 2021 03:52:29 GMT Subject: RFR: 8272067: Initial nroff manpage generation for JDK 18 In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 03:06:12 GMT, Joe Darcy wrote: >> Please review this trivial update to the generated manpages that updates their version from "JDK 17" to "JDK 18-ea". >> >> Thanks, >> David > > Marked as reviewed by darcy (Reviewer). Thanks for the review @jddarcy! ------------- PR: https://git.openjdk.java.net/jdk/pull/5028 From dholmes at openjdk.java.net Fri Aug 6 03:52:30 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 Aug 2021 03:52:30 GMT Subject: Integrated: 8272067: Initial nroff manpage generation for JDK 18 In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 01:53:51 GMT, David Holmes wrote: > Please review this trivial update to the generated manpages that updates their version from "JDK 17" to "JDK 18-ea". > > Thanks, > David This pull request has now been integrated. Changeset: ea02dade Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/ea02dade43409444b7c9f8b5065fded535b64f3f Stats: 26 lines in 26 files changed: 0 ins; 0 del; 26 mod 8272067: Initial nroff manpage generation for JDK 18 Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/5028 From naoto at openjdk.java.net Fri Aug 6 16:45:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 6 Aug 2021 16:45:41 GMT Subject: RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. Message-ID: Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. ------------- Commit messages: - 8264792: The NumberFormat for locale sq_XK formats price incorrectly. Changes: https://git.openjdk.java.net/jdk/pull/5033/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5033&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264792 Stats: 13 lines in 3 files changed: 6 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5033.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5033/head:pull/5033 PR: https://git.openjdk.java.net/jdk/pull/5033 From joehw at openjdk.java.net Fri Aug 6 17:31:33 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 6 Aug 2021 17:31:33 GMT Subject: RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5033 From iris at openjdk.java.net Fri Aug 6 21:09:28 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 6 Aug 2021 21:09:28 GMT Subject: RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5033 From iklam at openjdk.java.net Sat Aug 7 07:30:37 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 7 Aug 2021 07:30:37 GMT Subject: RFR: 8272113: Build compare script fails with differences in classlist Message-ID: The CDS classlist is generated with the `-XX:DumpLoadedClassList` option, which writes the name of the classes as they are being loaded. Since class loading order is affected by thread switching, the classes may appear in a non-deterministic order. Previously, the build compare script would sort the classlist before comparing. Since https://bugs.openjdk.java.net/browse/JDK-8272113, each class in the classlist has a new ID, so even after sorting, the contents would differ: $ diff classlist.1 classlist.2 207,208c207,208 < jdk/internal/misc/VM id: 201 < jdk/internal/util/SystemProps id: 202 --- > jdk/internal/misc/VM id: 202 > jdk/internal/util/SystemProps id: 201 The fix is to strip the id before doing the file comparison. Tested with: `mach5 remote-build -b linux-aarch64-cmp-baseline,macosx-x64-cmp-baseline,linux-x64-cmp-baseline,linux-arm32-open-cmp-baseline,windows-x64-cmp-baseline` ------------- Commit messages: - 8272113: Build compare script fails with differences in classlist Changes: https://git.openjdk.java.net/jdk/pull/5041/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5041&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272113 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5041.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5041/head:pull/5041 PR: https://git.openjdk.java.net/jdk/pull/5041 From ddong at openjdk.java.net Mon Aug 9 02:23:34 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 9 Aug 2021 02:23:34 GMT Subject: Withdrawn: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 15:20:50 GMT, Denghui Dong wrote: > Hi, > > Could I have a review of this improvement that eliminates 'is_large' check if the event size range is certain? > > JDK-8246260 introduced event large checks to reduce the recording size. > This check could be eliminated at compile/build time when one of the following conditions is satisfied: > 1. if the max size is < 128 > 2. if the min size is >= 128 > > The max size and the min size could be computed for the most native events at the generation phase. > > And I think this improvement may also be done for JDK events. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4670 From tschatzl at openjdk.java.net Mon Aug 9 08:17:34 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 9 Aug 2021 08:17:34 GMT Subject: RFR: 8272113: Build compare script fails with differences in classlist In-Reply-To: References: Message-ID: On Sat, 7 Aug 2021 07:25:01 GMT, Ioi Lam wrote: > The CDS classlist is generated with the `-XX:DumpLoadedClassList` option, which writes the name of the classes as they are being loaded. Since class loading order is affected by thread switching, the classes may appear in a non-deterministic order. > > Previously, the build compare script would sort the classlist before comparing. Since https://bugs.openjdk.java.net/browse/JDK-8272113, each class in the classlist has a new ID, so even after sorting, the contents would differ: > > > $ diff classlist.1 classlist.2 > 207,208c207,208 > < jdk/internal/misc/VM id: 201 > < jdk/internal/util/SystemProps id: 202 > --- >> jdk/internal/misc/VM id: 202 >> jdk/internal/util/SystemProps id: 201 > > > The fix is to strip the id before doing the file comparison. > > Tested with: > > `mach5 remote-build -b linux-aarch64-cmp-baseline,macosx-x64-cmp-baseline,linux-x64-cmp-baseline,linux-arm32-open-cmp-baseline,windows-x64-cmp-baseline` Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5041 From andrew at openjdk.java.net Mon Aug 9 13:43:33 2021 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Mon, 9 Aug 2021 13:43:33 GMT Subject: RFR: 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info In-Reply-To: <-WksWpFVEMR7cYkJViBGXJwLNsN8z3VeRBenp1p0Na8=.45e59698-96af-4223-a4d3-786606ea2d24@github.com> References: <-WksWpFVEMR7cYkJViBGXJwLNsN8z3VeRBenp1p0Na8=.45e59698-96af-4223-a4d3-786606ea2d24@github.com> Message-ID: <769yP8_XSNUxLWSE4Z9iVg4J_LIDC__ptOn32yWFVmU=.66da7960-2459-40f0-9495-1d5b26ed9d72@github.com> On Thu, 22 Jul 2021 16:43:26 GMT, Severin Gehwolf wrote: > Hi! > > Please review this tiny patch which removes the special casing of `--with-native-debug-symbols=external` for the static libs build. I don't see why this is needed. If no debug symbols are wanted `--with-native-debug-symbols=none` can be used to achieve the same effect. Therefore, I propose to remove this hunk. > > Testing: Inspecting of the log files and seeing that `-g` switch is there. Run the reproducer test on the resulting static libraries. > > Thoughts? > Yes. Are you suggesting that somebody is relying on these exact semantics? Configure **once** with `--with-native-debug-symbols=external` and expect static libs to have _no_ debuginfo (neither inline nor in an external file) while shared bits should have them in external files? That use case would still be possible by using two configurations. One with `--with-native-debug-symbols=external` and one with `--with-native-debug-symbols=none` and building only the needed targets each. Whereas, on the other hand, there is currently no option for someone who sets --with-native-debug-symbols=external and, rightly, expects the static libraries to have external debuginfo files. ------------- PR: https://git.openjdk.java.net/jdk/pull/4876 From hseigel at openjdk.java.net Mon Aug 9 15:47:37 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 9 Aug 2021 15:47:37 GMT Subject: RFR: 8272113: Build compare script fails with differences in classlist In-Reply-To: References: Message-ID: On Sat, 7 Aug 2021 07:25:01 GMT, Ioi Lam wrote: > The CDS classlist is generated with the `-XX:DumpLoadedClassList` option, which writes the name of the classes as they are being loaded. Since class loading order is affected by thread switching, the classes may appear in a non-deterministic order. > > Previously, the build compare script would sort the classlist before comparing. Since https://bugs.openjdk.java.net/browse/JDK-8272113, each class in the classlist has a new ID, so even after sorting, the contents would differ: > > > $ diff classlist.1 classlist.2 > 207,208c207,208 > < jdk/internal/misc/VM id: 201 > < jdk/internal/util/SystemProps id: 202 > --- >> jdk/internal/misc/VM id: 202 >> jdk/internal/util/SystemProps id: 201 > > > The fix is to strip the id before doing the file comparison. > > Tested with: > > `mach5 remote-build -b linux-aarch64-cmp-baseline,macosx-x64-cmp-baseline,linux-x64-cmp-baseline,linux-arm32-open-cmp-baseline,windows-x64-cmp-baseline` Looks good! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5041 From iklam at openjdk.java.net Mon Aug 9 15:53:36 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 9 Aug 2021 15:53:36 GMT Subject: RFR: 8272113: Build compare script fails with differences in classlist In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 08:14:44 GMT, Thomas Schatzl wrote: >> The CDS classlist is generated with the `-XX:DumpLoadedClassList` option, which writes the name of the classes as they are being loaded. Since class loading order is affected by thread switching, the classes may appear in a non-deterministic order. >> >> Previously, the build compare script would sort the classlist before comparing. Since https://bugs.openjdk.java.net/browse/JDK-8272113, each class in the classlist has a new ID, so even after sorting, the contents would differ: >> >> >> $ diff classlist.1 classlist.2 >> 207,208c207,208 >> < jdk/internal/misc/VM id: 201 >> < jdk/internal/util/SystemProps id: 202 >> --- >>> jdk/internal/misc/VM id: 202 >>> jdk/internal/util/SystemProps id: 201 >> >> >> The fix is to strip the id before doing the file comparison. >> >> Tested with: >> >> `mach5 remote-build -b linux-aarch64-cmp-baseline,macosx-x64-cmp-baseline,linux-x64-cmp-baseline,linux-arm32-open-cmp-baseline,windows-x64-cmp-baseline` > > Lgtm. Thanks @tschatzl and @hseigel for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5041 From iklam at openjdk.java.net Mon Aug 9 15:53:37 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 9 Aug 2021 15:53:37 GMT Subject: Integrated: 8272113: Build compare script fails with differences in classlist In-Reply-To: References: Message-ID: On Sat, 7 Aug 2021 07:25:01 GMT, Ioi Lam wrote: > The CDS classlist is generated with the `-XX:DumpLoadedClassList` option, which writes the name of the classes as they are being loaded. Since class loading order is affected by thread switching, the classes may appear in a non-deterministic order. > > Previously, the build compare script would sort the classlist before comparing. Since https://bugs.openjdk.java.net/browse/JDK-8272113, each class in the classlist has a new ID, so even after sorting, the contents would differ: > > > $ diff classlist.1 classlist.2 > 207,208c207,208 > < jdk/internal/misc/VM id: 201 > < jdk/internal/util/SystemProps id: 202 > --- >> jdk/internal/misc/VM id: 202 >> jdk/internal/util/SystemProps id: 201 > > > The fix is to strip the id before doing the file comparison. > > Tested with: > > `mach5 remote-build -b linux-aarch64-cmp-baseline,macosx-x64-cmp-baseline,linux-x64-cmp-baseline,linux-arm32-open-cmp-baseline,windows-x64-cmp-baseline` This pull request has now been integrated. Changeset: 272fcb42 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/272fcb423a79b5b8bb4a80679b6b48feca66ebca Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod 8272113: Build compare script fails with differences in classlist Reviewed-by: tschatzl, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/5041 From naoto at openjdk.java.net Mon Aug 9 16:25:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 9 Aug 2021 16:25:37 GMT Subject: Integrated: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. This pull request has now been integrated. Changeset: 41dc795d Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/41dc795d6c08af84aa6544cc5a5704dcf99386cf Stats: 13 lines in 3 files changed: 6 ins; 0 del; 7 mod 8264792: The NumberFormat for locale sq_XK formats price incorrectly. Reviewed-by: joehw, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5033 From frankfang at mapxus.com Wed Aug 11 02:04:39 2021 From: frankfang at mapxus.com (Frank Fang) Date: Wed, 11 Aug 2021 02:04:39 +0000 Subject: Failed to make jdk 12 Message-ID: <701D345C-9CA4-4BBB-841A-B04D962E5A69@mapxus.com> Hi, My OS is Mac OS BigSur 11.4. I can successfully execute bash configure, but failed to execute make images. Could you please kindly check the error message below? super thx. jdk12-06222165c35f bash configure configure: Configuration created at Wed Aug 11 09:18:19 CST 2021. checking for basename... /usr/bin/basename checking for bash... /bin/bash checking for cat... /bin/cat checking for chmod... /bin/chmod checking for cmp... /usr/bin/cmp checking for comm... /usr/bin/comm checking for cp... /bin/cp checking for cut... /usr/bin/cut checking for date... /bin/date checking for gdiff... no checking for diff... /usr/bin/diff checking for dirname... /usr/bin/dirname checking for echo... /bin/echo checking for expr... /bin/expr checking for file... /usr/bin/file checking for find... /usr/bin/find checking for head... /usr/bin/head checking for gunzip... /usr/bin/gunzip checking for pigz... no checking for gzip... /usr/bin/gzip checking for ln... /bin/ln checking for ls... /bin/ls checking for gmkdir... no checking for mkdir... /bin/mkdir checking for mktemp... /usr/bin/mktemp checking for mv... /bin/mv checking for nawk... no checking for gawk... no checking for awk... /usr/bin/awk checking for printf... /usr/bin/printf checking for greadlink... no checking for readlink... /usr/bin/readlink checking for rm... /bin/rm checking for rmdir... /bin/rmdir checking for sh... /bin/sh checking for sort... /usr/bin/sort checking for tail... /usr/bin/tail checking for gtar... no checking for tar... /usr/bin/tar checking for tee... /usr/bin/tee checking for touch... /usr/bin/touch checking for tr... /usr/bin/tr checking for uname... /usr/bin/uname checking for uniq... /usr/bin/uniq checking for wc... /usr/bin/wc checking for which... /usr/bin/which checking for xargs... /usr/bin/xargs checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for a sed that does not truncate output... /usr/bin/sed checking for cygpath... no checking for df... /bin/df checking for cpio... /usr/bin/cpio checking for nice... /usr/bin/nice checking for pandoc... no checking build system type... x86_64-apple-darwin20.5.0 checking host system type... x86_64-apple-darwin20.5.0 checking target system type... x86_64-apple-darwin20.5.0 checking openjdk-build os-cpu... macosx-x86_64 checking openjdk-target os-cpu... macosx-x86_64 checking compilation type... native checking for top-level directory... /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f checking if custom source is suppressed (openjdk-only)... no checking which debug level to use... release checking which variants of the JVM to build... server checking for xcodebuild... /usr/bin/xcodebuild checking for sdk name... checking for sysroot... /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk checking for toolchain path... checking for extra path... checking where to store configuration... in default location checking what configuration name to use... macosx-x86_64-server-release checking for apt-get... no checking for yum... no checking for brew... brew checking for gmake... no checking for make... /usr/bin/make configure: Testing potential make at /usr/bin/make, found using make in PATH configure: Using GNU make at /usr/bin/make (version: GNU Make 3.81) checking if make --output-sync is supported... no checking if find supports -delete... yes checking what type of tar was found... bsd checking that grep (/usr/bin/grep) -Fx handles empty lines in the pattern list correctly... yes checking for unzip... /usr/bin/unzip checking for zip... /usr/bin/zip checking for ldd... no checking for greadelf... no checking for readelf... no checking for dot... no checking for hg... /usr/local/bin/hg checking for git... /usr/local/bin/git checking for stat... /usr/bin/stat checking for time... /usr/bin/time checking for flock... no checking for dtrace... /usr/sbin/dtrace checking for gpatch... no checking for patch... /usr/bin/patch checking for dsymutil... /usr/bin/dsymutil checking for mig... /usr/bin/mig checking for xattr... /usr/bin/xattr checking for codesign... /usr/bin/codesign checking if openjdk_codesign certificate is present... no checking for SetFile... /usr/bin/SetFile checking bash version... 3.2.57 checking if bash supports pipefail... yes checking if bash supports errexit (-e)... yes checking for pkg-config... /usr/local/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for default LOG value... checking headless only... no checking for graphviz dot... no, cannot generate full docs checking for pandoc... no, cannot generate full docs checking full docs... no, missing dependencies checking for cacerts file... default checking for jni library path... default checking if packaged modules are kept... yes (default) checking for version string... 12-internal+0-adhoc.frank.jdk12-06222165c35f configure: Found potential Boot JDK using /usr/libexec/java_home checking for Boot JDK... /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home checking Boot JDK version... openjdk version "11.0.11" 2021-04-20 OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9) OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode) checking for java in Boot JDK... ok checking for javac in Boot JDK... ok checking for javadoc in Boot JDK... ok checking for jar in Boot JDK... ok checking for jarsigner in Boot JDK... ok checking if Boot JDK is 32 or 64 bits... 64 checking for local Boot JDK Class Data Sharing (CDS)... yes, created checking for Build JDK... yes, will use output dir configure: Xcode major version: 12 configure: Using default toolchain clang (clang/LLVM) checking for clang... /usr/bin/clang checking resolved symbolic links for CC... no symlink configure: Using clang C compiler version 12.0.5 [Apple clang version 12.0.5 (clang-1205.0.22.11) Target: x86_64-apple-darwin20.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin] checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/clang accepts -g... yes checking for /usr/bin/clang option to accept ISO C89... none needed checking for clang++... /usr/bin/clang++ checking resolved symbolic links for CXX... no symlink configure: Using clang C++ compiler version 12.0.5 [Apple clang version 12.0.5 (clang-1205.0.22.11) Target: x86_64-apple-darwin20.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin] checking whether we are using the GNU C++ compiler... yes checking whether /usr/bin/clang++ accepts -g... yes checking how to run the C preprocessor... /usr/bin/clang -E checking how to run the C++ preprocessor... /usr/bin/clang++ -E configure: Using clang linker version 650.9 [@(#)PROGRAM:ld PROJECT:ld64-650.9] checking for ar... ar configure: Rewriting AR to "/usr/bin/ar" checking for lipo... /usr/bin/lipo checking for otool... /usr/bin/otool checking for install_name_tool... /usr/bin/install_name_tool checking for strip... strip configure: Rewriting STRIP to "/usr/bin/strip" checking for nm... nm configure: Rewriting NM to "/usr/bin/nm" checking for gobjdump... no checking for objdump... objdump configure: Rewriting OBJDUMP to "/usr/bin/objdump" checking for c++filt... c++filt configure: Rewriting CXXFILT to "/usr/bin/c++filt" checking for jtreg... no checking for jtreg test harness... no, not found checking for jmh (Java Microbenchmark Harness)... no, disabled checking for jib... no checking if the C compiler supports "-m64"... yes checking if the C++ compiler supports "-m64"... yes checking if both compilers support "-m64"... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking stdio.h usability... yes checking stdio.h presence... yes checking for stdio.h... yes checking size of int *... 8 checking for target address size... 64 bits checking whether byte ordering is bigendian... no checking if native warnings are errors... true (default) checking for library containing clock_gettime... none required checking if the C compiler supports "-ffp-contract=off"... yes checking if the C++ compiler supports "-ffp-contract=off"... yes checking if both compilers support "-ffp-contract=off"... yes checking what type of native debug symbols to use... external checking for dtrace tool... /usr/sbin/dtrace checking sys/sdt.h usability... yes checking sys/sdt.h presence... yes checking for sys/sdt.h... yes checking if dtrace should be built... yes, dependencies present checking if Hotspot gtest unit tests should be built... yes checking cups/cups.h usability... yes checking cups/cups.h presence... yes checking for cups/cups.h... yes checking cups/ppd.h usability... yes checking cups/ppd.h presence... yes checking for cups/ppd.h... yes Using freetype: bundled checking for which libjpeg to use... bundled checking for which giflib to use... bundled checking for PNG... no checking for which libpng to use... bundled checking for compress in -lz... yes checking for which zlib to use... system checking for system zlib functionality... ok checking for which lcms to use... bundled checking for cos in -lm... yes checking for dlopen in -ldl... yes checking if shenandoah can be built... yes checking if zgc can be built... no, platform not supported checking if jvmci module jdk.internal.vm.ci should be built... yes checking if graal module jdk.internal.vm.compiler should be built... yes checking if aot should be enabled... yes checking if cds should be enabled... yes checking if elliptic curve crypto implementation is present... yes checking if jtreg failure handler should be built... no, missing jtreg checking if the CDS classlist generation should be enabled... yes checking if any translations should be excluded... no checking if static man pages should be copied... yes checking if a default CDS archive should be generated... yes checking for number of cores... 8 checking for memory size... 16384 MB checking for appropriate number of jobs to run in parallel... 8 checking flags for boot jdk java command ... -Duser.language=en -Duser.country=US -XX:+UnlockDiagnosticVMOptions -XX:-VerifySharedSpaces -XX:SharedArchiveFile=/Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/build/macosx-x86_64-server-release/configure-support/classes.jsa -Xshare:auto checking flags for boot jdk java command for big workloads... -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 checking flags for bootcycle boot jdk java command for big workloads... -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 checking flags for boot jdk java command for small workloads... -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 checking whether to use sjavac... no checking whether to use javac server... yes checking If precompiled header is enabled... yes checking is ccache enabled... no checking if build directory is on local disk... yes checking JVM features for JVM variant 'server'... "aot cds cmsgc compiler1 compiler2 dtrace epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs" configure: creating /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/build/macosx-x86_64-server-release/configure-support/config.status config.status: creating /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/build/macosx-x86_64-server-release/spec.gmk config.status: creating /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/build/macosx-x86_64-server-release/bootcycle-spec.gmk config.status: creating /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/build/macosx-x86_64-server-release/buildjdk-spec.gmk config.status: creating /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/build/macosx-x86_64-server-release/compare.sh config.status: creating /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/build/macosx-x86_64-server-release/Makefile ==================================================== A new configuration has been successfully created in /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/build/macosx-x86_64-server-release using default settings. Configuration summary: * Debug level: release * HS debug level: product * JVM variants: server * JVM features: server: 'aot cds cmsgc compiler1 compiler2 dtrace epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs' * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64 * Version string: 12-internal+0-adhoc.frank.jdk12-06222165c35f (12-internal) Tools summary: * Boot JDK: openjdk version "11.0.11" 2021-04-20 OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9) OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode) (at /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home) * Toolchain: clang (clang/LLVM from Xcode 12.5.1) * C Compiler: Version 12.0.5 (at /usr/bin/clang) * C++ Compiler: Version 12.0.5 (at /usr/bin/clang++) Build performance summary: * Cores to use: 8 * Memory limit: 16384 MB make images Building target 'images' in configuration 'macosx-x86_64-server-release' Warning: No SCM configuration present and no .src-rev Compiling 8 files for BUILD_TOOLS_LANGTOOLS Parsing 2 properties into enum-like class for jdk.compiler Compiling 13 properties into resource bundles for jdk.javadoc Compiling Compiling 12 7 properties properties into into resource resource bundles bundles for for jdk.jdeps jdk.jshell Compiling 19 properties into resource bundles for jdk.compiler Compiling 117 files for BUILD_java.compiler.interim Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s) Compiling 2 files for BUILD_JVMTI_TOOLS Compiling 1 files for BUILD_JFR_TOOLS Compiling 396 files for BUILD_jdk.compiler.interim ld: warning: directory not found for option '-F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/JavaVM.framework/Frameworks' Creating support/modules_libs/java.base/server/libjvm.dylib from 921 file(s) Creating hotspot/variant-server/libjvm/gtest/libjvm.dylib from 104 file(s) Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s) /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/src/hotspot/share/runtime/arguments.cpp:1452:35: error: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Werror,-Wstring-compare] if (old_java_vendor_url_bug != DEFAULT_VENDOR_URL_BUG) { ^ ~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. make[3]: *** [/Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/arguments.o] Error 1 make[3]: *** Waiting for unfinished jobs.... Compiling 304 files for BUILD_jdk.javadoc.interim Compiling 162 files for BUILD_TOOLS_JDK Compiling 3 files for BUILD_VM_COMPILER_MATCH_PROCESSOR Compiling 31 files for BUILD_JRTFS Compiling 5 files for BUILD_VM_COMPILER_NODEINFO_PROCESSOR Compiling 2 files for COMPILE_DEPEND Compiling 188 files for BUILD_jdk.rmic.interim Creating support/modules_libs/java.base/jrt-fs.jar Compiling 3 files for BUILD_VM_COMPILER_OPTIONS_PROCESSOR make[2]: *** [hotspot-server-libs] Error 2 make[2]: *** Waiting for unfinished jobs.... Compiling 14 files for BUILD_VM_COMPILER_REPLACEMENTS_PROCESSOR Compiling 3 files for BUILD_VM_COMPILER_SERVICEPROVIDER_PROCESSOR Creating buildtools/jdk.vm.compiler.match.processor.jar Creating buildtools/jdk.vm.compiler.nodeinfo.processor.jar Creating buildtools/jdk.vm.compiler.options.processor.jar Creating buildtools/jdk.vm.compiler.replacements.verifier.jar Creating buildtools/jdk.vm.compiler.serviceprovider.processor.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. ERROR: Build failed for target 'images' in configuration 'macosx-x86_64-server-release' (exit code 2) Stopping sjavac server === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_objs_arguments.o: /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/src/hotspot/share/runtime/arguments.cpp:1452:35: error: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Werror,-Wstring-compare] if (old_java_vendor_url_bug != DEFAULT_VENDOR_URL_BUG) { ^ ~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. * All command lines available in /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/build/macosx-x86_64-server-release/make-support/failure-logs. === End of repeated output === No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: See doc/building.html#troubleshooting for assistance. make[1]: *** [main] Error 2 make: *** [images] Error 2 From shade at redhat.com Wed Aug 11 05:20:02 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 11 Aug 2021 08:20:02 +0300 Subject: Failed to make jdk 12 In-Reply-To: <701D345C-9CA4-4BBB-841A-B04D962E5A69@mapxus.com> References: <701D345C-9CA4-4BBB-841A-B04D962E5A69@mapxus.com> Message-ID: On 8/11/21 5:04 AM, Frank Fang wrote: > /Users/frank/Desktop/Work/Indoor_Positioning/software/jdk12-06222165c35f/src/hotspot/share/runtime/arguments.cpp:1452:35: error: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Werror,-Wstring-compare] > if (old_java_vendor_url_bug != DEFAULT_VENDOR_URL_BUG) { > ^ ~~~~~~~~~~~~~~~~~~~~~~ > 1 error generated. JDK 12 is in deep end-of-life, it is expected not to be easily buildable with current toolchains. You can have some luck with disabling the warnings-as-errors by passing --disable-warnings-as-errors to configure. Or, --with-extra-cflags=-Wno-error. -- Thanks, -Aleksey From sgehwolf at openjdk.java.net Wed Aug 11 18:04:33 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 11 Aug 2021 18:04:33 GMT Subject: RFR: 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790 Message-ID: Please review this simple build fix to correct the type done in JDK-8255790. After the patch correct external library is added to the `libfontmanager.so` link command when building with `--with-harfbuzz=system`. Thoughts? ------------- Commit messages: - 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790 Changes: https://git.openjdk.java.net/jdk/pull/5091/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5091&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272332 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5091.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5091/head:pull/5091 PR: https://git.openjdk.java.net/jdk/pull/5091 From prr at openjdk.java.net Wed Aug 11 18:24:27 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 11 Aug 2021 18:24:27 GMT Subject: RFR: 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790 In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 17:58:04 GMT, Severin Gehwolf wrote: > Please review this simple build fix to correct the type done in JDK-8255790. After the patch correct external library is added to the `libfontmanager.so` link command when building with `--with-harfbuzz=system`. > > Thoughts? Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5091 From sgehwolf at openjdk.java.net Thu Aug 12 08:52:26 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 12 Aug 2021 08:52:26 GMT Subject: RFR: 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790 In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 18:21:14 GMT, Phil Race wrote: >> Please review this simple build fix to correct the typo done in JDK-8255790. After the patch correct external library is added to the `libfontmanager.so` link command when building with `--with-harfbuzz=system`. >> >> Thoughts? > > Marked as reviewed by prr (Reviewer). Thanks for the review @prrace! ------------- PR: https://git.openjdk.java.net/jdk/pull/5091 From sgehwolf at openjdk.java.net Thu Aug 12 08:55:27 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 12 Aug 2021 08:55:27 GMT Subject: Integrated: 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790 In-Reply-To: References: Message-ID: <7IpFm6xn8v_jBS53nVe0miGQ8mT9rdBoCAO-lHHezco=.36eeb442-56a0-4155-a7a9-4a0203f096a3@github.com> On Wed, 11 Aug 2021 17:58:04 GMT, Severin Gehwolf wrote: > Please review this simple build fix to correct the typo done in JDK-8255790. After the patch correct external library is added to the `libfontmanager.so` link command when building with `--with-harfbuzz=system`. > > Thoughts? This pull request has now been integrated. Changeset: d38b3143 Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/d38b31438dd4730ee2149c02277d60c35b9d7d81 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790 Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/5091 From jjg at openjdk.java.net Fri Aug 13 03:59:49 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 13 Aug 2021 03:59:49 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments Message-ID: Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. There are three cases to consider: * The comment itself is missing: this was already checked and reported as "missing comment". * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. A new test is added, focussing on the different forms of empty/missing descriptions, as described above. ------------- Commit messages: - JDK-8272374: doclint should report missing "body" comments Changes: https://git.openjdk.java.net/jdk/pull/5106/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5106&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272374 Stats: 281 lines in 37 files changed: 152 ins; 10 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/5106.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5106/head:pull/5106 PR: https://git.openjdk.java.net/jdk/pull/5106 From kcr at openjdk.java.net Fri Aug 13 15:46:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Aug 2021 15:46:27 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 03:51:23 GMT, Jonathan Gibbons wrote: > Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. > > It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. > > There are three cases to consider: > > * The comment itself is missing: this was already checked and reported as "missing comment". > * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". > * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". > > No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. > > Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) > > Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. > > A new test is added, focussing on the different forms of empty/missing descriptions, as described above. I tested this by using it to generate the JavaFX docs. We have 62 new warnings for methods with empty descriptions that we otherwise would not have easily found. ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/5106 From david.holmes at oracle.com Mon Aug 16 00:31:43 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Aug 2021 10:31:43 +1000 Subject: Building jdk on OS/X In-Reply-To: References: Message-ID: <171353ad-ad66-2ce8-a924-d888b01ebf46@oracle.com> Redirecting to the build-dev alias. On 15/08/2021 1:22 am, Michael Hall wrote: > Seeing the recent comments on build problems I was curious enough to try building on OS/X. > I followed the directions here? > https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html > I get errors like? > > === Output from failing command(s) repeated here === > * For target buildtools_buildtools_hotspot_tools_classes__the.BUILD_TOOLS_HOTSPOT_batch: > warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/ridl.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/jurt.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/juh.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/unoil.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program": no such file or directory > warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20191126-bin.jar": no such file or directory > error: warnings found and -Werror specified > 1 error > 7 warnings I would not expect any of the Java based build tools to be picking up any default classpath elements from the environment. But I suppose this could be a problem if your boot JDK actually refers to wrapper scripts that do set such a classpath. I would need to see more details from the build log as to what was actually being executed. Cheers, David > First try I moved the concerned application (OpenOffice.app) and framework (BSF4ooRexx.framework) out of the way. The error persisted. Seeing that make clean removed make but not config files I removed the jdk directory and cloned the repository again and the error persisted. > After spending some time trying to determine how to change compile options to eliminate the 'warnings as error' it occurred to me that these are not compile errors and no compiler option change will probably be a fix. > > My questions are? > > Where is these files having been present persisted? > > Why does building the jdk have anything to do with them? > From david.holmes at oracle.com Mon Aug 16 01:44:59 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Aug 2021 11:44:59 +1000 Subject: Building jdk on OS/X In-Reply-To: <149F8F2A-83F9-4CCA-B47A-ACD167849877@gmail.com> References: <171353ad-ad66-2ce8-a924-d888b01ebf46@oracle.com> <149F8F2A-83F9-4CCA-B47A-ACD167849877@gmail.com> Message-ID: On 16/08/2021 11:05 am, Michael Hall wrote: > > >> On Aug 15, 2021, at 7:31 PM, David Holmes wrote: >> >> Redirecting to the build-dev alias. >> >> On 15/08/2021 1:22 am, Michael Hall wrote: >>> Seeing the recent comments on build problems I was curious enough to try building on OS/X. >>> I followed the directions here? >>> https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html > >>> I get errors like? >>> === Output from failing command(s) repeated here === >>> * For target buildtools_buildtools_hotspot_tools_classes__the.BUILD_TOOLS_HOTSPOT_batch: >>> warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar": no such file or directory >>> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/ridl.jar": no such file or directory >>> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/jurt.jar": no such file or directory >>> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/juh.jar": no such file or directory >>> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/unoil.jar": no such file or directory >>> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program": no such file or directory >>> warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20191126-bin.jar": no such file or directory >>> error: warnings found and -Werror specified >>> 1 error >>> 7 warnings >> >> I would not expect any of the Java based build tools to be picking up any default classpath elements from the environment. But I suppose this could be a problem if your boot JDK actually refers to wrapper scripts that do set such a classpath. I would need to see more details from the build log as to what was actually being executed. > > It appears to be the OS/X Terminal application that picks it up and adds it to the environment and the installation process picks it up from the environment there. > > I had deleted the /etc/profile entries that Rony had indicated. Make still picked up a couple of the errors above. I rebooted and then got a clean build. Just quitting and restarting Terminal probably would have also worked. > I had just installed the newer BSF4ooRexx version mentioned by Rony. It also had the export CLASSPATH entries for both BSF4ooRexx and OpenOffice so it appears that the BSF4ooRexx install is the source for both of those. I removed them and had been able to build the JDK. > Right after that I got your email. So I uninstalled BSF4ooRexx and reinstalled to get the /etc/profile export CLASSPATH?s again. > The jdk build was still working. > oops. > I quit and restarted Terminal. > It failed as before. If you are interested in the build.log it is pretty much as above. Sorry I meant the full log, in particular the configure part that shows what tools are being used. > Building target 'images' in configuration 'macosx-x86_64-server-release' > Compiling 1 files for BUILD_TOOLS_HOTSPOT > Compiling 8 files for BUILD_TOOLS_LANGTOOLS > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/lib": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/bin": no such file or directory > error: warnings found and -Werror specified > 1 error > 2 warnings > make[3]: *** [/Users/mjh/jdk/build/macosx-x86_64-server-release/buildtools/buildtools/hotspot_tools_classes/_the.BUILD_TOOLS_HOTSPOT_batch] Error 1 > make[2]: *** [buildtools-hotspot] Error 2 > make[2]: *** Waiting for unfinished jobs.... > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/lib": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/bin": no such file or directory > error: warnings found and -Werror specified > 1 error > 2 warnings > make[3]: *** [/Users/mjh/jdk/build/macosx-x86_64-server-release/buildtools/langtools_tools_classes/_the.BUILD_TOOLS_LANGTOOLS_batch] Error 1 > make[2]: *** [buildtools-langtools] Error 2 > > ERROR: Build failed for target 'images' in configuration 'macosx-x86_64-server-release' (exit code 2) > > If you are considering supporting this and not setting to ignore the environment I think you might get the not found type errors because the paths involved include Mac alias?s. You might need to look and see if they are getting resolved correctly. Normally this might not be a concern for your builds either. No invocation of a Java based tool in the build process should be setting any kind of classpath that refers to system level packages like that. However if your boot JDK is what is doing that then there may not be anything the build can do about it. Cheers, David > > From david.holmes at oracle.com Mon Aug 16 03:47:54 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Aug 2021 13:47:54 +1000 Subject: Building jdk on OS/X In-Reply-To: <769A8F97-A748-40C9-97C8-A19D805A6743@gmail.com> References: <171353ad-ad66-2ce8-a924-d888b01ebf46@oracle.com> <149F8F2A-83F9-4CCA-B47A-ACD167849877@gmail.com> <769A8F97-A748-40C9-97C8-A19D805A6743@gmail.com> Message-ID: <00151ac1-5ac9-5433-5cfa-3a9d141d9b53@oracle.com> Hi Michael, On 16/08/2021 12:15 pm, Michael Hall wrote: > > >>> It failed as before. If you are interested in the build.log it is >>> pretty much as above. >> >> Sorry I meant the full log, in particular the configure part that >> shows what tools are being used. >> >>> >> >> No invocation of a Java based tool in the build process should be >> setting any kind of classpath that refers to system level packages >> like that. >> However if your boot JDK is what is doing that then there may not be >> anything the build can do about it. > > > The config log is somewhat larger I can include it if you want or put it > somewhere you can see it. Somewhere I could see would be good - thanks. > I?m not quite following what you are saying. No java tool is at fault > here except in possibly honoring the setting of the CLASSPATH > environment variable. They should only honour that variable if no explicit classpath is set for the tool invocation, and IIUC all our build tool invocations should be setting an explicit classpath as you don't want the build to accidentally pick things up. Cheers, David ----- > /etc/profile is a Unix environment config file isn?t it? Thats where > CLASSPATH is being set. > I haven?t seen what Rony is doing in his BSF4ooRexx install here > anywhere else. I guess his intention is to make BSF4ooRexx available to > all users. Not that if he had done it at the user level it would have > made much difference to me. I suppose anyone else could make java > environment changes to Terminal initialization scripts as well I might > not be aware of. > If the build process has to honor any CLASSPATH environment settings > there might not be anything you can do. If you can ignore it or do some > verification of paths included maybe you could choose to ignore some > paths. I?m not familiar enough to know if you can do this or not. If the > build process itself never relies on the CLASSPATH environment variable > you could just unset it to start? I just did that and am again getting a > clean build. My background isn?t that extensively Unix. > With what Rony has told me I can manage the BSF4ooRexx install and still > build the jdk. New to that. If anyone else does what Rony does or any > other BSF400Rexs user tries to build the JDK I don?t know what else you > could do. > From mik3hall at gmail.com Mon Aug 16 01:05:34 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 15 Aug 2021 20:05:34 -0500 Subject: Building jdk on OS/X In-Reply-To: <171353ad-ad66-2ce8-a924-d888b01ebf46@oracle.com> References: <171353ad-ad66-2ce8-a924-d888b01ebf46@oracle.com> Message-ID: <149F8F2A-83F9-4CCA-B47A-ACD167849877@gmail.com> > On Aug 15, 2021, at 7:31 PM, David Holmes wrote: > > Redirecting to the build-dev alias. > > On 15/08/2021 1:22 am, Michael Hall wrote: >> Seeing the recent comments on build problems I was curious enough to try building on OS/X. >> I followed the directions here? >> https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html > >> I get errors like? >> === Output from failing command(s) repeated here === >> * For target buildtools_buildtools_hotspot_tools_classes__the.BUILD_TOOLS_HOTSPOT_batch: >> warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/ridl.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/jurt.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/juh.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/unoil.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program": no such file or directory >> warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20191126-bin.jar": no such file or directory >> error: warnings found and -Werror specified >> 1 error >> 7 warnings > > I would not expect any of the Java based build tools to be picking up any default classpath elements from the environment. But I suppose this could be a problem if your boot JDK actually refers to wrapper scripts that do set such a classpath. I would need to see more details from the build log as to what was actually being executed. It appears to be the OS/X Terminal application that picks it up and adds it to the environment and the installation process picks it up from the environment there. I had deleted the /etc/profile entries that Rony had indicated. Make still picked up a couple of the errors above. I rebooted and then got a clean build. Just quitting and restarting Terminal probably would have also worked. I had just installed the newer BSF4ooRexx version mentioned by Rony. It also had the export CLASSPATH entries for both BSF4ooRexx and OpenOffice so it appears that the BSF4ooRexx install is the source for both of those. I removed them and had been able to build the JDK. Right after that I got your email. So I uninstalled BSF4ooRexx and reinstalled to get the /etc/profile export CLASSPATH?s again. The jdk build was still working. oops. I quit and restarted Terminal. It failed as before. If you are interested in the build.log it is pretty much as above. Building target 'images' in configuration 'macosx-x86_64-server-release' Compiling 1 files for BUILD_TOOLS_HOTSPOT Compiling 8 files for BUILD_TOOLS_LANGTOOLS warning: [path] bad path element "/Applications/OpenOffice.app/Contents/lib": no such file or directory warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/bin": no such file or directory error: warnings found and -Werror specified 1 error 2 warnings make[3]: *** [/Users/mjh/jdk/build/macosx-x86_64-server-release/buildtools/buildtools/hotspot_tools_classes/_the.BUILD_TOOLS_HOTSPOT_batch] Error 1 make[2]: *** [buildtools-hotspot] Error 2 make[2]: *** Waiting for unfinished jobs.... warning: [path] bad path element "/Applications/OpenOffice.app/Contents/lib": no such file or directory warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/bin": no such file or directory error: warnings found and -Werror specified 1 error 2 warnings make[3]: *** [/Users/mjh/jdk/build/macosx-x86_64-server-release/buildtools/langtools_tools_classes/_the.BUILD_TOOLS_LANGTOOLS_batch] Error 1 make[2]: *** [buildtools-langtools] Error 2 ERROR: Build failed for target 'images' in configuration 'macosx-x86_64-server-release' (exit code 2) If you are considering supporting this and not setting to ignore the environment I think you might get the not found type errors because the paths involved include Mac alias?s. You might need to look and see if they are getting resolved correctly. Normally this might not be a concern for your builds either. From mik3hall at gmail.com Mon Aug 16 02:15:43 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 15 Aug 2021 21:15:43 -0500 Subject: Building jdk on OS/X In-Reply-To: References: <171353ad-ad66-2ce8-a924-d888b01ebf46@oracle.com> <149F8F2A-83F9-4CCA-B47A-ACD167849877@gmail.com> Message-ID: <769A8F97-A748-40C9-97C8-A19D805A6743@gmail.com> >> It failed as before. If you are interested in the build.log it is pretty much as above. > > Sorry I meant the full log, in particular the configure part that shows what tools are being used. > >> > > No invocation of a Java based tool in the build process should be setting any kind of classpath that refers to system level packages like that. > However if your boot JDK is what is doing that then there may not be anything the build can do about it. The config log is somewhat larger I can include it if you want or put it somewhere you can see it. I?m not quite following what you are saying. No java tool is at fault here except in possibly honoring the setting of the CLASSPATH environment variable. /etc/profile is a Unix environment config file isn?t it? Thats where CLASSPATH is being set. I haven?t seen what Rony is doing in his BSF4ooRexx install here anywhere else. I guess his intention is to make BSF4ooRexx available to all users. Not that if he had done it at the user level it would have made much difference to me. I suppose anyone else could make java environment changes to Terminal initialization scripts as well I might not be aware of. If the build process has to honor any CLASSPATH environment settings there might not be anything you can do. If you can ignore it or do some verification of paths included maybe you could choose to ignore some paths. I?m not familiar enough to know if you can do this or not. If the build process itself never relies on the CLASSPATH environment variable you could just unset it to start? I just did that and am again getting a clean build. My background isn?t that extensively Unix. With what Rony has told me I can manage the BSF4ooRexx install and still build the jdk. New to that. If anyone else does what Rony does or any other BSF400Rexs user tries to build the JDK I don?t know what else you could do. From mik3hall at gmail.com Mon Aug 16 04:36:00 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 15 Aug 2021 23:36:00 -0500 Subject: Building jdk on OS/X In-Reply-To: <00151ac1-5ac9-5433-5cfa-3a9d141d9b53@oracle.com> References: <171353ad-ad66-2ce8-a924-d888b01ebf46@oracle.com> <149F8F2A-83F9-4CCA-B47A-ACD167849877@gmail.com> <769A8F97-A748-40C9-97C8-A19D805A6743@gmail.com> <00151ac1-5ac9-5433-5cfa-3a9d141d9b53@oracle.com> Message-ID: <981D2301-D330-46B2-8AEB-C860FFBFAD3D@gmail.com> > On Aug 15, 2021, at 10:47 PM, David Holmes wrote: > > Hi Michael, > > On 16/08/2021 12:15 pm, Michael Hall wrote: >>>> It failed as before. If you are interested in the build.log it is pretty much as above. >>> >>> Sorry I meant the full log, in particular the configure part that shows what tools are being used. >>> >>>> >>> >>> No invocation of a Java based tool in the build process should be setting any kind of classpath that refers to system level packages like that. However if your boot JDK is what is doing that then there may not be anything the build can do about it. >> The config log is somewhat larger I can include it if you want or put it somewhere you can see it. > > Somewhere I could see would be good - thanks. http://mikehall.pairserver.com/configure.log > >> I?m not quite following what you are saying. No java tool is at fault here except in possibly honoring the setting of the CLASSPATH environment variable. > > They should only honour that variable if no explicit classpath is set for the tool invocation, and IIUC all our build tool invocations should be setting an explicit classpath as you don't want the build to accidentally pick things up. > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/lib": no such file or directory compiler.properties # 0: path compiler.warn.path.element.not.found=\ bad path element "{0}": no such file or directory I guess I was assuming javac. I was going to try to isolate removing which -Werror worked around things but then got Romy?s post. You should be able to reproduce just by doing something like export CLASSPATH=$CLASSPATH:/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar And then build on OS/X make images From hannesw at openjdk.java.net Mon Aug 16 11:45:25 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 16 Aug 2021 11:45:25 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments In-Reply-To: References: Message-ID: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> On Fri, 13 Aug 2021 03:51:23 GMT, Jonathan Gibbons wrote: > Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. > > It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. > > There are three cases to consider: > > * The comment itself is missing: this was already checked and reported as "missing comment". > * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". > * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". > > No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. > > Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) > > Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. > > A new test is added, focussing on the different forms of empty/missing descriptions, as described above. Looks good. One thing I wonder about is why you only look for `@deprecated` in the first block tag. I guess it is just a convention to add this tag at the first position? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 203: > 201: // Don't report an empty description if the comment begins with @deprecated, > 202: // because javadoc will use the content of that tag in summary tables. > 203: if (firstTag.getKind() != DocTree.Kind.DEPRECATED) { Why do we only check the first block tag here? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 204: > 202: // because javadoc will use the content of that tag in summary tables. > 203: if (firstTag.getKind() != DocTree.Kind.DEPRECATED) { > 204: env.messages.report(MISSING, Kind.WARNING, tree, "dc.empty.description"); Is there a reason to not use `reportMissing` here? ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5106 From jjg at openjdk.java.net Mon Aug 16 17:11:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 17:11:29 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments In-Reply-To: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> References: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> Message-ID: <8_n_Wcn6QF4nXLkgtIgrlTSKESOi5HmTpC_a4pcUKMM=.c9499fce-31b5-40ee-a806-2e92d5894bd6@github.com> On Fri, 13 Aug 2021 09:20:19 GMT, Hannes Walln?fer wrote: >> Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. >> >> It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. >> >> There are three cases to consider: >> >> * The comment itself is missing: this was already checked and reported as "missing comment". >> * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". >> * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". >> >> No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. >> >> Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) >> >> Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. >> >> A new test is added, focussing on the different forms of empty/missing descriptions, as described above. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 203: > >> 201: // Don't report an empty description if the comment begins with @deprecated, >> 202: // because javadoc will use the content of that tag in summary tables. >> 203: if (firstTag.getKind() != DocTree.Kind.DEPRECATED) { > > Why do we only check the first block tag here? Various reasons, 1. It seems the convention is to simply prefix an existing comment with `@deprecated` or to replace the existing body description with `@deprecated reason-why-deprecated` 2. This is only for the case when there is no body description; it seems hard to imagine that someone would start a comment with `@see` `@param` `@return` etc and then have the `@deprecated` tag. That being said, it would be easy enough to change the code to check for any instance of `@deprecated`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5106 From jjg at openjdk.java.net Mon Aug 16 17:18:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 17:18:29 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments In-Reply-To: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> References: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> Message-ID: On Fri, 13 Aug 2021 09:21:40 GMT, Hannes Walln?fer wrote: >> Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. >> >> It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. >> >> There are three cases to consider: >> >> * The comment itself is missing: this was already checked and reported as "missing comment". >> * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". >> * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". >> >> No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. >> >> Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) >> >> Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. >> >> A new test is added, focussing on the different forms of empty/missing descriptions, as described above. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 204: > >> 202: // because javadoc will use the content of that tag in summary tables. >> 203: if (firstTag.getKind() != DocTree.Kind.DEPRECATED) { >> 204: env.messages.report(MISSING, Kind.WARNING, tree, "dc.empty.description"); > > Is there a reason to not use `reportMissing` here? It doesn't have the right signature. `reportMissing` reports a missing comment on an element; here, we're reporting a missing description within a `DocTree`. There's a similar occurrence at line 1214. ------------- PR: https://git.openjdk.java.net/jdk/pull/5106 From jjg at openjdk.java.net Mon Aug 16 17:22:31 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 17:22:31 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments In-Reply-To: <8_n_Wcn6QF4nXLkgtIgrlTSKESOi5HmTpC_a4pcUKMM=.c9499fce-31b5-40ee-a806-2e92d5894bd6@github.com> References: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> <8_n_Wcn6QF4nXLkgtIgrlTSKESOi5HmTpC_a4pcUKMM=.c9499fce-31b5-40ee-a806-2e92d5894bd6@github.com> Message-ID: <2nzruNweIsajakC9eWy6UFJVrR6m5T4TDQuSvxP5PaY=.ec56f7db-f398-4d74-aa9f-f8c0b47a690b@github.com> On Mon, 16 Aug 2021 17:08:13 GMT, Jonathan Gibbons wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 203: >> >>> 201: // Don't report an empty description if the comment begins with @deprecated, >>> 202: // because javadoc will use the content of that tag in summary tables. >>> 203: if (firstTag.getKind() != DocTree.Kind.DEPRECATED) { >> >> Why do we only check the first block tag here? > > Various reasons, > 1. It seems the convention is to simply prefix an existing comment with `@deprecated` or to replace the existing body description with `@deprecated reason-why-deprecated` > 2. This is only for the case when there is no body description; it seems hard to imagine that someone would start a comment with `@see` `@param` `@return` etc and then have the `@deprecated` tag. > > That being said, it would be easy enough to change the code to check for any instance of `@deprecated`. Given that the downstream code does not impose any ordering restrictions on the tags, it is probably with doing the same here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5106 From jjg at openjdk.java.net Mon Aug 16 17:38:05 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 17:38:05 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments [v2] In-Reply-To: References: Message-ID: > Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. > > It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. > > There are three cases to consider: > > * The comment itself is missing: this was already checked and reported as "missing comment". > * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". > * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". > > No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. > > Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) > > Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. > > A new test is added, focussing on the different forms of empty/missing descriptions, as described above. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: address review comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5106/files - new: https://git.openjdk.java.net/jdk/pull/5106/files/60c6f569..6c875688 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5106&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5106&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5106.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5106/head:pull/5106 PR: https://git.openjdk.java.net/jdk/pull/5106 From jjg at openjdk.java.net Mon Aug 16 20:51:32 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 20:51:32 GMT Subject: Integrated: JDK-8272374: doclint should report missing "body" comments In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 03:51:23 GMT, Jonathan Gibbons wrote: > Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. > > It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. > > There are three cases to consider: > > * The comment itself is missing: this was already checked and reported as "missing comment". > * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". > * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". > > No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. > > Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) > > Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. > > A new test is added, focussing on the different forms of empty/missing descriptions, as described above. This pull request has now been integrated. Changeset: ae45592d Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/ae45592d3304f50aa9e8e114416a41e7899fe37b Stats: 280 lines in 37 files changed: 151 ins; 10 del; 119 mod 8272374: doclint should report missing "body" comments Reviewed-by: kcr, hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/5106 From rhalade at openjdk.java.net Tue Aug 17 04:06:39 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 17 Aug 2021 04:06:39 GMT Subject: RFR: 8225083: Remove Google certificate that is expiring in December 2021 Message-ID: Removed the expiring root certificate. ------------- Commit messages: - 8225083: Remove Google certificate that is expiring in December 2021 Changes: https://git.openjdk.java.net/jdk/pull/5137/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5137&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225083 Stats: 34 lines in 2 files changed: 0 ins; 31 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5137.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5137/head:pull/5137 PR: https://git.openjdk.java.net/jdk/pull/5137 From xuelei at openjdk.java.net Tue Aug 17 04:37:27 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 17 Aug 2021 04:37:27 GMT Subject: RFR: 8225083: Remove Google certificate that is expiring in December 2021 In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 03:59:15 GMT, Rajan Halade wrote: > Removed the expiring root certificate. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5137 From mullan at openjdk.java.net Tue Aug 17 12:43:27 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 17 Aug 2021 12:43:27 GMT Subject: RFR: 8225083: Remove Google certificate that is expiring in December 2021 In-Reply-To: References: Message-ID: <6xGubzuZmm84ZJvq_BQ3yNsqQzI0ym_236JtvLrTgGE=.0801538a-f606-4f59-9ab9-fd68f67a4491@github.com> On Tue, 17 Aug 2021 03:59:15 GMT, Rajan Halade wrote: > Removed the expiring root certificate. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5137 From rhalade at openjdk.java.net Tue Aug 17 16:04:30 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 17 Aug 2021 16:04:30 GMT Subject: Integrated: 8225083: Remove Google certificate that is expiring in December 2021 In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 03:59:15 GMT, Rajan Halade wrote: > Removed the expiring root certificate. This pull request has now been integrated. Changeset: 1cbf41a8 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/1cbf41a87b153c010c51fdbae832e00314422193 Stats: 34 lines in 2 files changed: 0 ins; 31 del; 3 mod 8225083: Remove Google certificate that is expiring in December 2021 Reviewed-by: xuelei, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/5137 From jjg at openjdk.java.net Wed Aug 18 22:12:37 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 18 Aug 2021 22:12:37 GMT Subject: RFR: JDK-8272667: substandard error messages from the docs build Message-ID: Please review a small (delete one character) change to improve the error messages reported when bad HTML is detected when post-processing the output from pandoc to generate the docs. The change is just to pass the filename as an argument to the command, instead of just piping the input to stdin. As a result, the name of any file containing bad input is reported in the message, instead of the message simply referring to `` ------------- Commit messages: - JDK-8272667: substandard error messages from the docs build Changes: https://git.openjdk.java.net/jdk/pull/5175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5175&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272667 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5175/head:pull/5175 PR: https://git.openjdk.java.net/jdk/pull/5175 From darcy at openjdk.java.net Wed Aug 18 22:29:24 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 18 Aug 2021 22:29:24 GMT Subject: RFR: JDK-8272667: substandard error messages from the docs build In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 22:06:13 GMT, Jonathan Gibbons wrote: > Please review a small (delete one character) change to improve the error messages reported when bad HTML is detected when post-processing the output from pandoc to generate the docs. > > The change is just to pass the filename as an argument to the command, instead of just piping the input to stdin. As a result, the name of any file containing bad input is reported in the message, instead of the message simply referring to `` Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5175 From iris at openjdk.java.net Wed Aug 18 22:36:21 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 18 Aug 2021 22:36:21 GMT Subject: RFR: JDK-8272667: substandard error messages from the docs build In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 22:06:13 GMT, Jonathan Gibbons wrote: > Please review a small (delete one character) change to improve the error messages reported when bad HTML is detected when post-processing the output from pandoc to generate the docs. > > The change is just to pass the filename as an argument to the command, instead of just piping the input to stdin. As a result, the name of any file containing bad input is reported in the message, instead of the message simply referring to `` Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5175 From jjg at openjdk.java.net Wed Aug 18 23:43:28 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 18 Aug 2021 23:43:28 GMT Subject: Integrated: JDK-8272667: substandard error messages from the docs build In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 22:06:13 GMT, Jonathan Gibbons wrote: > Please review a small (delete one character) change to improve the error messages reported when bad HTML is detected when post-processing the output from pandoc to generate the docs. > > The change is just to pass the filename as an argument to the command, instead of just piping the input to stdin. As a result, the name of any file containing bad input is reported in the message, instead of the message simply referring to `` This pull request has now been integrated. Changeset: 6d3d4795 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/6d3d47957ef03c90ed3b1cb7a48902366cd1bc27 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8272667: substandard error messages from the docs build Reviewed-by: darcy, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5175 From jiefu at openjdk.java.net Thu Aug 19 07:16:35 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 19 Aug 2021 07:16:35 GMT Subject: RFR: 8272700: [macos] Build failure with Xcode 13.0 after JDK-8264848 Message-ID: Hi all, May I get reviews for this small change? The failure is caused by incorrect flag `-mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120`. The following command works fine with Xcode 12.0 but fails with Xcode 13.0. clang++ -mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120 a.cpp Thanks. Best regards, Jie ------------- Commit messages: - 8272700: [macos] Build failure with Xcode 13.0 after JDK-8264848 Changes: https://git.openjdk.java.net/jdk/pull/5180/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5180&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272700 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5180.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5180/head:pull/5180 PR: https://git.openjdk.java.net/jdk/pull/5180 From dholmes at openjdk.java.net Thu Aug 19 08:07:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 19 Aug 2021 08:07:24 GMT Subject: RFR: 8272700: [macos] Build failure with Xcode 13.0 after JDK-8264848 In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 07:09:52 GMT, Jie Fu wrote: > Hi all, > > May I get reviews for this small change? > > The failure is caused by incorrect flag `-mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120`. > > The following command works fine with Xcode 12.0 but fails with Xcode 13.0. > > clang++ -mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120 a.cpp > > > Thanks. > Best regards, > Jie Looks good - and I would say trivial, except I can't believe the original code has actually been doing what it was supposed to do, so the impact on things is less clear. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5180 From samuel_thomas at brown.edu Thu Aug 19 14:55:45 2021 From: samuel_thomas at brown.edu (Thomas, Samuel) Date: Thu, 19 Aug 2021 10:55:45 -0400 Subject: Compiling JDK with gprof Message-ID: Hi all, I'm trying to run some program profiling of the JDK for a research project and am trying to use gprof to gather specific performance metrics of routines and subroutines in the JDK. However, I don't have much experience with the build process other than following the setup instructions, and it seems rather complex to include flags (i.e., -pg if GCC is used) in the make instructions. Could someone help me find where to add additional flags to the build instructions? Thank you for your help! Best, Sam From shade at redhat.com Thu Aug 19 14:59:35 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 19 Aug 2021 16:59:35 +0200 Subject: Compiling JDK with gprof In-Reply-To: References: Message-ID: <71019ecd-1656-11fa-ead6-d91b0f22b64d@redhat.com> On 8/19/21 4:55 PM, Thomas, Samuel wrote: > Could someone help me find where to add additional flags to the build > instructions? Look in configure help? $ sh ./configure --help | grep flags --with-extra-cflags extra flags to be used when compiling jdk c-files --with-extra-cxxflags extra flags to be used when compiling jdk c++-files --with-extra-ldflags extra flags to be used when linking jdk --with-extra-asflags extra flags to be passed to the assembler -- Thanks, -Aleksey From samuel_thomas at brown.edu Thu Aug 19 15:09:30 2021 From: samuel_thomas at brown.edu (Thomas, Samuel) Date: Thu, 19 Aug 2021 11:09:30 -0400 Subject: Compiling JDK with gprof In-Reply-To: <71019ecd-1656-11fa-ead6-d91b0f22b64d@redhat.com> References: <71019ecd-1656-11fa-ead6-d91b0f22b64d@redhat.com> Message-ID: Great, this is exactly what I was looking for. Thank you for your help! Best, Sam On Thu, Aug 19, 2021 at 10:59 AM Aleksey Shipilev wrote: > On 8/19/21 4:55 PM, Thomas, Samuel wrote: > > Could someone help me find where to add additional flags to the build > > instructions? > > Look in configure help? > > $ sh ./configure --help | grep flags > --with-extra-cflags extra flags to be used when compiling jdk > c-files > --with-extra-cxxflags extra flags to be used when compiling jdk > c++-files > --with-extra-ldflags extra flags to be used when linking jdk > --with-extra-asflags extra flags to be passed to the assembler > > -- > Thanks, > -Aleksey > > From jiefu at openjdk.java.net Thu Aug 19 23:15:30 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 19 Aug 2021 23:15:30 GMT Subject: RFR: 8272700: [macos] Build failure with Xcode 13.0 after JDK-8264848 In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 08:04:39 GMT, David Holmes wrote: >> Hi all, >> >> May I get reviews for this small change? >> >> The failure is caused by incorrect flag `-mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120`. >> >> The following command works fine with Xcode 12.0 but fails with Xcode 13.0. >> >> clang++ -mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120 a.cpp >> >> >> Thanks. >> Best regards, >> Jie > > Looks good - and I would say trivial, except I can't believe the original code has actually been doing what it was supposed to do, so the impact on things is less clear. > > Thanks, > David Thanks @dholmes-ora . ------------- PR: https://git.openjdk.java.net/jdk/pull/5180 From jiefu at openjdk.java.net Thu Aug 19 23:15:30 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 19 Aug 2021 23:15:30 GMT Subject: Integrated: 8272700: [macos] Build failure with Xcode 13.0 after JDK-8264848 In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 07:09:52 GMT, Jie Fu wrote: > Hi all, > > May I get reviews for this small change? > > The failure is caused by incorrect flag `-mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120`. > > The following command works fine with Xcode 12.0 but fails with Xcode 13.0. > > clang++ -mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120 a.cpp > > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: d007be09 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/d007be0952abdc8beb7b68ebf7529a939162307b Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8272700: [macos] Build failure with Xcode 13.0 after JDK-8264848 Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/5180 From serb at openjdk.java.net Sun Aug 22 06:28:18 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 22 Aug 2021 06:28:18 GMT Subject: RFR: 8272805: Avoid looking up standard charsets Message-ID: This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. See https://github.com/openjdk/jdk/pull/5063 and https://github.com/openjdk/jdk/pull/4951 In many places standard charsets are looked up via their names, for example: absolutePath.getBytes("UTF-8"); This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: absolutePath.getBytes(StandardCharsets.UTF_8); The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. This change includes: * demo/utils * jdk.xx packages * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. Also checked for "aliases" usage. Some performance discussion: https://github.com/openjdk/jdk/pull/5063 Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the "java.naming"(the change there is not straightforward, will do it later). Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. ------------- Commit messages: - Fix related imports - Merge branch 'master' into standard-encodings-in-non-public-modules - Cleanup UnsupportedEncodingException - Update PacketStream.java - Rollback TextTests, should be compatible with jdk1.4 - Rollback TextRenderTests, should be compatible with jdk1.4 - Cleanup the UnsupportedEncodingException - aliases for ISO_8859_1 - Update imageio - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/5210/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272805 Stats: 333 lines in 48 files changed: 91 ins; 123 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/5210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210 PR: https://git.openjdk.java.net/jdk/pull/5210 From weijun at openjdk.java.net Sun Aug 22 13:22:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 22 Aug 2021 13:22:38 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: <0eO4SD_N9lrP5k5bhEejUKXeMauRC8zuc_slUJSrc5c=.c886ae36-5039-450f-9293-5f9910ce432d@github.com> On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. The security related change looks fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From alanb at openjdk.java.net Sun Aug 22 15:12:26 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 22 Aug 2021 15:12:26 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342: > 340: > 341: try { > 342: for (String line : Files.readAllLines(statusPath, UTF_8)) { The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want. ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From github.com+741251+turbanoff at openjdk.java.net Sun Aug 22 18:34:26 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 22 Aug 2021 18:34:26 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too. ![???????????](https://user-images.githubusercontent.com/741251/130366051-ef093bf1-d7d9-4ad1-91e7-5df5af8678af.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From serb at openjdk.java.net Sun Aug 22 23:02:06 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 22 Aug 2021 23:02:06 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Sergey Bylokhov 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 14 additional commits since the last revision: - Update the usage of Files.readAllLines() - Update datatransfer - Merge branch 'master' into standard-encodings-in-non-public-modules - Merge branch 'master' into standard-encodings-in-non-public-modules - Fix related imports - Merge branch 'master' into standard-encodings-in-non-public-modules - Cleanup UnsupportedEncodingException - Update PacketStream.java - Rollback TextTests, should be compatible with jdk1.4 - Rollback TextRenderTests, should be compatible with jdk1.4 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/37357100...e7127644 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5210/files - new: https://git.openjdk.java.net/jdk/pull/5210/files/2d9c80b8..e7127644 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00-01 Stats: 3598 lines in 210 files changed: 2055 ins; 1115 del; 428 mod Patch: https://git.openjdk.java.net/jdk/pull/5210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210 PR: https://git.openjdk.java.net/jdk/pull/5210 From naoto at openjdk.java.net Mon Aug 23 00:26:31 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 23 Aug 2021 00:26:31 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/c262b06f...e7127644 Looks good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From mbaesken at openjdk.java.net Mon Aug 23 06:43:30 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Mon, 23 Aug 2021 06:43:30 GMT Subject: Integrated: JDK-8271142: package help is not displayed for missing X11/extensions/Xrandr.h In-Reply-To: References: Message-ID: <1lQbFNGZJOQbC8GaH-YDBZ1TDwSFzlbT-Sze_6LERsA=.7bd338f8-bf03-43c5-9a10-152d8c95a71d@github.com> On Thu, 22 Jul 2021 13:42:09 GMT, Matthias Baesken wrote: > Please review the following change. > On SUSE Linux 15 configure was running into this error, because of a missing X11 header : > > checking for X11/extensions/Xrandr.h... no > configure: error: Could not find all X11 headers (shape.h Xrender.h Xrandr.h XTest.h Intrinsic.h). > > I wondered about the missing package help output, we should display some hint what packages are missing. > In help.m4, PKGHANDLER was detected as /usr/bin/zypper . > However only the exact string zypper is checked, this should be relaxed. > Afterwards, the package - help was working nicely : > > checking for X11/extensions/Xrandr.h... no > configure: error: Could not find all X11 headers (shape.h Xrender.h Xrandr.h XTest.h Intrinsic.h). > You might be able to fix this by running 'sudo zypper install libX11-devel libXext-devel libXrender-devel libXrandr-devel libXtst-devel libXt-devel libXi-devel'. This pull request has now been integrated. Changeset: b7f75c0a Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/b7f75c0a735f0cf40ae2288d1d0ae96a571a4155 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod 8271142: package help is not displayed for missing X11/extensions/Xrandr.h Reviewed-by: clanger ------------- PR: https://git.openjdk.java.net/jdk/pull/4873 From dfuchs at openjdk.java.net Mon Aug 23 09:36:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 23 Aug 2021 09:36:40 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/db47f6e1...e7127644 Changes to http server look good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From serb at openjdk.java.net Mon Aug 23 19:34:34 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 Aug 2021 19:34:34 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov wrote: > I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too. Updated as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From serb at openjdk.java.net Mon Aug 23 19:34:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 Aug 2021 19:34:38 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman wrote: >> Sergey Bylokhov 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 14 additional commits since the last revision: >> >> - Update the usage of Files.readAllLines() >> - Update datatransfer >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Fix related imports >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Cleanup UnsupportedEncodingException >> - Update PacketStream.java >> - Rollback TextTests, should be compatible with jdk1.4 >> - Rollback TextRenderTests, should be compatible with jdk1.4 >> - ... and 4 more: https://git.openjdk.java.net/jdk/compare/465eb90c...e7127644 > > src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342: > >> 340: >> 341: try { >> 342: for (String line : Files.readAllLines(statusPath, UTF_8)) { > > The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want. Thank you for the suggestion, I have fixed this and a few other places as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 23 20:54:36 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 23 Aug 2021 20:54:36 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/aaa7beaf...e7127644 Marked as reviewed by turbanoff at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From azvegint at openjdk.java.net Tue Aug 24 13:09:37 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 24 Aug 2021 13:09:37 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8c6e27c3...e7127644 Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From magnus.ihse.bursie at oracle.com Wed Aug 25 12:03:05 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 25 Aug 2021 14:03:05 +0200 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> Message-ID: Hi Jaikiran, I'm glad to see this issue finally getting some love and attention! :) I don't fully support those "inclinations" that say that the old API should not change. I think keeping the old random order of store() would mean a missed chance to do good, otherwise a lot of Java programs will never get reproducible output of property files. We do have a chance of helping the community, in a single stroke, to make lots of application (more) reproducible without any programmer effort. There is a growing community pushing for reproducible builds (see e.g. https://reproducible-builds.org). Java programs tend to have reproducibility issues due to several cases of non-determinism in the Java platform, and I really think we should try to rectify that. The specification for store() does not say anything about the order properties are written, so I think the implementation is free to change this to a deterministic order. As long as files written by an updated version of store() can be read by old versions (and vice versa) there will be no compatibility issue in Java programs. And since the old (current...) order is non-deterministic, it seems exceedingly unlikely that any external program depends on the order currently generated by store(). The problem is with the time stamp, which the spec states should be present. I understand why changing this might need a new method. But I think we should try to steer users to this new method. Otherwise it is likely not to be used by those who should use it (the programmers) to the detrimental effect of users who get properties file which change for no good reason. Having an "attractive" name is definitely part of that. The name should scream "use me as a first hand choice for storing properties to a file". I don't really get that feeling from storeCanonical(). > One thing I do remember is the JDK build (through the make files) > would have certain Java code it would call to do some build steps. Is > there a easy way to find all such build related Java files within the > JDK? I would like to see if there are any references/calls to this > method from those build files. I am doing some searches myself, but > knowing where to search will give me more confidence that I haven't > missed out any. The java buildtool sources are located in the "make" directory, more specifically in "make/jdk/src", "make/langtools/src" and "make/src" (yeah, I know -- a cleanup is way overdue). I did a quick search now but could not find any references to Properties.store(). I'm trying to remember if we create properties during the build... We have several instances where .properties files in the Java source code are converted to hard-coded classes (for performance), and other where .properties files are copied verbatim. Ah, right, they are "cleaned" beforehand. We used to do this by a Java program, but nowadays they are mangled by sed. I think replacing that sed script with a trivial Java program doing storeCanonical() would be on the list of things to do. I can assist with that, when you are starting to get your implementation done. We might also write something as part of the jlink process that gets embedded in the resulting jimage; not quite sure about that. You should find that code in the normal src/ codebase though. /Magnus From magnus.ihse.bursie at oracle.com Wed Aug 25 12:24:01 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 25 Aug 2021 14:24:01 +0200 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> Message-ID: <21db7af3-3689-e1ac-04a0-627530b4bf57@oracle.com> On 2021-08-25 14:03, Magnus Ihse Bursie wrote: > Hi Jaikiran, > > I'm glad to see this issue finally getting some love and attention! :) > > I don't fully support those "inclinations" that say that the old API > should not change. I think keeping the old random order of store() > would mean a missed chance to do good, otherwise a lot of Java > programs will never get reproducible output of property files. We do > have a chance of helping the community, in a single stroke, to make > lots of application (more) reproducible without any programmer effort. > There is a growing community pushing for reproducible builds (see e.g. > https://reproducible-builds.org). Java programs tend to have > reproducibility issues due to several cases of non-determinism in the > Java platform, and I really think we should try to rectify that. > > The specification for store() does not say anything about the order > properties are written, so I think the implementation is free to > change this to a deterministic order. As long as files written by an > updated version of store() can be read by old versions (and vice > versa) there will be no compatibility issue in Java programs. And > since the old (current...) order is non-deterministic, it seems > exceedingly unlikely that any external program depends on the order > currently generated by store(). > > The problem is with the time stamp, which the spec states should be > present. I understand why changing this might need a new method. This got me thinking a bit. If we are willing to change the spec slightly, we could use the standard `SOURCE_DATE_EPOCH` environment variable. Many tools support this already. The meaning of this variable is that, if present, tools that generate timestamps should use that value instead. [1] It seems unlikely that a user running Java with `SOURCE_DATE_EPOCH` should get upset if the behavior of Properties.store() changed. Without this variable, store() would generate timestamps as usual of the current time. /Magnus [1] https://reproducible-builds.org/docs/source-date-epoch/ > But I think we should try to steer users to this new method. Otherwise > it is likely not to be used by those who should use it (the > programmers) to the detrimental effect of users who get properties > file which change for no good reason. Having an "attractive" name is > definitely part of that. The name should scream "use me as a first > hand choice for storing properties to a file". I don't really get that > feeling from storeCanonical(). > >> One thing I do remember is the JDK build (through the make files) >> would have certain Java code it would call to do some build steps. Is >> there a easy way to find all such build related Java files within the >> JDK? I would like to see if there are any references/calls to this >> method from those build files. I am doing some searches myself, but >> knowing where to search will give me more confidence that I haven't >> missed out any. > > The java buildtool sources are located in the "make" directory, more > specifically in "make/jdk/src", "make/langtools/src" and "make/src" > (yeah, I know -- a cleanup is way overdue). I did a quick search now > but could not find any references to Properties.store(). > > I'm trying to remember if we create properties during the build... We > have several instances where .properties files in the Java source code > are converted to hard-coded classes (for performance), and other where > .properties files are copied verbatim. Ah, right, they are "cleaned" > beforehand. We used to do this by a Java program, but nowadays they > are mangled by sed. I think replacing that sed script with a trivial > Java program doing storeCanonical() would be on the list of things to > do. I can assist with that, when you are starting to get your > implementation done. > > We might also write something as part of the jlink process that gets > embedded in the resulting jimage; not quite sure about that. You > should find that code in the normal src/ codebase though. > > /Magnus From ihse at openjdk.java.net Wed Aug 25 14:13:41 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 25 Aug 2021 14:13:41 GMT Subject: RFR: 8272859: Javadoc external links should only have feature version number in URL Message-ID: Link to license terms from the JavaDoc API footer is broken in point releases (for example, 16.0.2). Instead of using VERSION_NUMBER, VERSION_FEATURE should be used, ------------- Commit messages: - 8272859: Javadoc external links should only have feature version number in URL Changes: https://git.openjdk.java.net/jdk/pull/5253/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5253&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272859 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5253.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5253/head:pull/5253 PR: https://git.openjdk.java.net/jdk/pull/5253 From jai.forums2013 at gmail.com Wed Aug 25 14:34:13 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 25 Aug 2021 20:04:13 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> Message-ID: <757c55d2-f346-98a4-3435-3f2da188a142@gmail.com> On 25/08/21 5:33 pm, Magnus Ihse Bursie wrote: > ... > > The problem is with the time stamp, which the spec states should be > present. I understand why changing this might need a new method. But I > think we should try to steer users to this new method. Otherwise it is > likely not to be used by those who should use it (the programmers) to > the detrimental effect of users who get properties file which change > for no good reason. Having an "attractive" name is definitely part of > that. The name should scream "use me as a first hand choice for > storing properties to a file". I don't really get that feeling from > storeCanonical(). > I'm not saying we should do this, but one other way to scream, is to deprecate (but not for removal) the old "store" APIs and point the users to the new ones (if we introduce them). Similar to what "save" API in that same class currently does. -Jaikiran From iris at openjdk.java.net Wed Aug 25 16:30:27 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 25 Aug 2021 16:30:27 GMT Subject: RFR: 8272859: Javadoc external links should only have feature version number in URL In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 13:57:29 GMT, Magnus Ihse Bursie wrote: > Link to license terms from the JavaDoc API footer is broken in point releases (for example, 16.0.2). > > Instead of using VERSION_NUMBER, VERSION_FEATURE should be used, Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5253 From ihse at openjdk.java.net Thu Aug 26 10:03:31 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 26 Aug 2021 10:03:31 GMT Subject: Integrated: 8272859: Javadoc external links should only have feature version number in URL In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 13:57:29 GMT, Magnus Ihse Bursie wrote: > Link to license terms from the JavaDoc API footer is broken in point releases (for example, 16.0.2). > > Instead of using VERSION_NUMBER, VERSION_FEATURE should be used, This pull request has now been integrated. Changeset: b94fd32f Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/b94fd32f08bbb0012874eb918a4a1fe2d06eb943 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8272859: Javadoc external links should only have feature version number in URL Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5253 From jai.forums2013 at gmail.com Thu Aug 26 14:07:48 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 26 Aug 2021 19:37:48 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> Message-ID: <10b4024a-cad0-e6ee-3eb6-db8db0a6fe29@gmail.com> Hello Magnus, On 25/08/21 5:33 pm, Magnus Ihse Bursie wrote: > ... >> One thing I do remember is the JDK build (through the make files) >> would have certain Java code it would call to do some build steps. Is >> there a easy way to find all such build related Java files within the >> JDK? I would like to see if there are any references/calls to this >> method from those build files. I am doing some searches myself, but >> knowing where to search will give me more confidence that I haven't >> missed out any. > > The java buildtool sources are located in the "make" directory, more > specifically in "make/jdk/src", "make/langtools/src" and "make/src" > (yeah, I know -- a cleanup is way overdue). I did a quick search now > but could not find any references to Properties.store(). > Thank you for that. I went ahead and verified it again and like you note, I don't see any usages in this code. > I'm trying to remember if we create properties during the build... We > have several instances where .properties files in the Java source code > are converted to hard-coded classes (for performance), and other where > .properties files are copied verbatim. Ah, right, they are "cleaned" > beforehand. We used to do this by a Java program, but nowadays they > are mangled by sed. I think replacing that sed script with a trivial > Java program doing storeCanonical() would be on the list of things to > do. I can assist with that, when you are starting to get your > implementation done. Thank you. Once the initial draft version is ready, I will contact you. > > We might also write something as part of the jlink process that gets > embedded in the resulting jimage; not quite sure about that. You > should find that code in the normal src/ codebase though. I had a look at the the jlink and image building code and I haven't found any references/usages in this area. -Jaikiran From ihse at openjdk.java.net Fri Aug 27 10:29:36 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 27 Aug 2021 10:29:36 GMT Subject: RFR: 8273072: Avoid using += in configure Message-ID: JDK-8272700 was created to fix a bug in a variable assignment in configure. While it fixed the bug, it kept the problematic syntax that caused the bug in the first place. We do not use the `FOO+="appended"` syntax for appending to variables in shell scripts, since this differs from what you'd expect (and what make produces) in that no space is added before the appended text. Instead, we use the longer, but clearer `FOO="$FOO appended"`. ------------- Commit messages: - 8273072: Avoid using += in configure Changes: https://git.openjdk.java.net/jdk/pull/5276/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5276&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273072 Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5276.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5276/head:pull/5276 PR: https://git.openjdk.java.net/jdk/pull/5276 From ihse at openjdk.java.net Fri Aug 27 12:52:44 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 27 Aug 2021 12:52:44 GMT Subject: RFR: 8258465: Headless build fails due to missing X11 headers on linux Message-ID: It turned out that JDK-8255785 was incorrectly verified, and headless do indeed need X headers. This fix is a revert (anti-delta) of JDK-8255785. ------------- Commit messages: - 8258465: Headless build fails due to missing X11 headers on linux Changes: https://git.openjdk.java.net/jdk/pull/5278/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5278&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258465 Stats: 5 lines in 1 file changed: 1 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5278/head:pull/5278 PR: https://git.openjdk.java.net/jdk/pull/5278 From jiefu at openjdk.java.net Fri Aug 27 12:56:22 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 27 Aug 2021 12:56:22 GMT Subject: RFR: 8273072: Avoid using += in configure In-Reply-To: References: Message-ID: <7kF08ZDId-PTzorQUSxajBP7v0ViqkE_FDJRQu2dstU=.e80d1651-c81a-4175-a986-e96b027978c3@github.com> On Fri, 27 Aug 2021 10:21:26 GMT, Magnus Ihse Bursie wrote: > JDK-8272700 was created to fix a bug in a variable assignment in configure. While it fixed the bug, it kept the problematic syntax that caused the bug in the first place. > > We do not use the `FOO+="appended"` syntax for appending to variables in shell scripts, since this differs from what you'd expect (and what make produces) in that no space is added before the appended text. > > Instead, we use the longer, but clearer `FOO="$FOO appended"`. Please update the copyright year in `jdk-version.m4`. Shall we also fix this one? ./devkit/createMacosxDevkit.sh: EXCLUDE_ARGS+="--exclude=$ex " ------------- PR: https://git.openjdk.java.net/jdk/pull/5276 From shade at openjdk.java.net Fri Aug 27 13:06:27 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 27 Aug 2021 13:06:27 GMT Subject: RFR: 8258465: Headless build fails due to missing X11 headers on linux In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 12:46:14 GMT, Magnus Ihse Bursie wrote: > It turned out that JDK-8255785 was incorrectly verified, and headless do indeed need X headers. This fix is a revert (anti-delta) of JDK-8255785. Looks good! Looks like a trivial reversal. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5278 From ihse at openjdk.java.net Fri Aug 27 13:14:53 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 27 Aug 2021 13:14:53 GMT Subject: RFR: 8273072: Avoid using += in configure In-Reply-To: References: Message-ID: <01c7dkNsHIsApUNoV3GZu8IRZ8AuBAhOgejtW1UhSKE=.fed1d574-1a5b-417f-8b4f-60934e1b9b14@github.com> On Fri, 27 Aug 2021 10:21:26 GMT, Magnus Ihse Bursie wrote: > JDK-8272700 was created to fix a bug in a variable assignment in configure. While it fixed the bug, it kept the problematic syntax that caused the bug in the first place. > > We do not use the `FOO+="appended"` syntax for appending to variables in shell scripts, since this differs from what you'd expect (and what make produces) in that no space is added before the appended text. > > Instead, we use the longer, but clearer `FOO="$FOO appended"`. Thank you for spotting this! The exclude argument in the devkit builder looks like it has never worked. :( ------------- PR: https://git.openjdk.java.net/jdk/pull/5276 From ihse at openjdk.java.net Fri Aug 27 13:14:52 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 27 Aug 2021 13:14:52 GMT Subject: RFR: 8273072: Avoid using += in configure [v2] In-Reply-To: References: Message-ID: > JDK-8272700 was created to fix a bug in a variable assignment in configure. While it fixed the bug, it kept the problematic syntax that caused the bug in the first place. > > We do not use the `FOO+="appended"` syntax for appending to variables in shell scripts, since this differs from what you'd expect (and what make produces) in that no space is added before the appended text. > > Instead, we use the longer, but clearer `FOO="$FOO appended"`. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix code review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5276/files - new: https://git.openjdk.java.net/jdk/pull/5276/files/a8e0c35a..3083307d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5276&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5276&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5276.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5276/head:pull/5276 PR: https://git.openjdk.java.net/jdk/pull/5276 From ihse at openjdk.java.net Fri Aug 27 13:16:26 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 27 Aug 2021 13:16:26 GMT Subject: Integrated: 8258465: Headless build fails due to missing X11 headers on linux In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 12:46:14 GMT, Magnus Ihse Bursie wrote: > It turned out that JDK-8255785 was incorrectly verified, and headless do indeed need X headers. This fix is a revert (anti-delta) of JDK-8255785. This pull request has now been integrated. Changeset: 596b0755 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/596b075591c4b2fe01bee7142f4d0a5f892647ed Stats: 5 lines in 1 file changed: 1 ins; 3 del; 1 mod 8258465: Headless build fails due to missing X11 headers on linux Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/5278 From jiefu at openjdk.java.net Fri Aug 27 13:18:25 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 27 Aug 2021 13:18:25 GMT Subject: RFR: 8273072: Avoid using += in configure [v2] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 13:14:52 GMT, Magnus Ihse Bursie wrote: >> JDK-8272700 was created to fix a bug in a variable assignment in configure. While it fixed the bug, it kept the problematic syntax that caused the bug in the first place. >> >> We do not use the `FOO+="appended"` syntax for appending to variables in shell scripts, since this differs from what you'd expect (and what make produces) in that no space is added before the appended text. >> >> Instead, we use the longer, but clearer `FOO="$FOO appended"`. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix code review comments make/devkit/createMacosxDevkit.sh line 105: > 103: > 104: for ex in $EXCLUDE_DIRS; do > 105: EXCLUDE_ARGS="$EXCLUDE_ARGS --exclude=$ex " Thanks for your update. This copyright should be updated too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5276 From dholmes at openjdk.java.net Fri Aug 27 13:25:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 27 Aug 2021 13:25:31 GMT Subject: RFR: 8273072: Avoid using += in configure [v2] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 13:14:52 GMT, Magnus Ihse Bursie wrote: >> JDK-8272700 was created to fix a bug in a variable assignment in configure. While it fixed the bug, it kept the problematic syntax that caused the bug in the first place. >> >> We do not use the `FOO+="appended"` syntax for appending to variables in shell scripts, since this differs from what you'd expect (and what make produces) in that no space is added before the appended text. >> >> Instead, we use the longer, but clearer `FOO="$FOO appended"`. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix code review comments I wouldn't have considered the m4 files as "shell scripts" and I'm surprised that the same operator in makefiles adds extra spaces - that seems unintuitive. But using the expanded format is fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5276 From jiefu at openjdk.java.net Fri Aug 27 13:58:03 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 27 Aug 2021 13:58:03 GMT Subject: RFR: 8273072: Avoid using += in configure [v3] In-Reply-To: <1NjTQqlIuc36cHBLY_8XXakq5eNPY1JK3EOLZc2lnZc=.787a1b43-71a0-4cf7-b84f-422dfa581310@github.com> References: <1NjTQqlIuc36cHBLY_8XXakq5eNPY1JK3EOLZc2lnZc=.787a1b43-71a0-4cf7-b84f-422dfa581310@github.com> Message-ID: On Fri, 27 Aug 2021 13:53:56 GMT, Magnus Ihse Bursie wrote: >> JDK-8272700 was created to fix a bug in a variable assignment in configure. While it fixed the bug, it kept the problematic syntax that caused the bug in the first place. >> >> We do not use the `FOO+="appended"` syntax for appending to variables in shell scripts, since this differs from what you'd expect (and what make produces) in that no space is added before the appended text. >> >> Instead, we use the longer, but clearer `FOO="$FOO appended"`. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year and remove space Marked as reviewed by jiefu (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5276 From ihse at openjdk.java.net Fri Aug 27 13:57:59 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 27 Aug 2021 13:57:59 GMT Subject: RFR: 8273072: Avoid using += in configure [v3] In-Reply-To: References: Message-ID: <1NjTQqlIuc36cHBLY_8XXakq5eNPY1JK3EOLZc2lnZc=.787a1b43-71a0-4cf7-b84f-422dfa581310@github.com> > JDK-8272700 was created to fix a bug in a variable assignment in configure. While it fixed the bug, it kept the problematic syntax that caused the bug in the first place. > > We do not use the `FOO+="appended"` syntax for appending to variables in shell scripts, since this differs from what you'd expect (and what make produces) in that no space is added before the appended text. > > Instead, we use the longer, but clearer `FOO="$FOO appended"`. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix copyright year and remove space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5276/files - new: https://git.openjdk.java.net/jdk/pull/5276/files/3083307d..5dbc5ed1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5276&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5276&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5276.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5276/head:pull/5276 PR: https://git.openjdk.java.net/jdk/pull/5276 From ihse at openjdk.java.net Fri Aug 27 13:58:05 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 27 Aug 2021 13:58:05 GMT Subject: RFR: 8273072: Avoid using += in configure [v2] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 13:22:31 GMT, David Holmes wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix code review comments > > I wouldn't have considered the m4 files as "shell scripts" and I'm surprised that the same operator in makefiles adds extra spaces - that seems unintuitive. But using the expanded format is fine. > > Thanks, > David @dholmes-ora The configure script is mostly shell code, with some m4 abstractions in it. (Autoconf calls this mongrel language for "m4sh". I'd rate it a 1 out of 5. Recommendation: stay away. ;-)) Makefiles, otoh, is a proper language, albeit badly designed. I'm actually a bit unsure if a construct like `FOO+=BAR` with no spaces would add a space (I still believe so, since make is so word-oriented), but we always use `FOO += BAR`. (Which is not possible in shells since that would not count as a variable assignment but a command execution...) ------------- PR: https://git.openjdk.java.net/jdk/pull/5276 From ihse at openjdk.java.net Fri Aug 27 13:58:08 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 27 Aug 2021 13:58:08 GMT Subject: RFR: 8273072: Avoid using += in configure [v2] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 13:15:36 GMT, Jie Fu wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix code review comments > > make/devkit/createMacosxDevkit.sh line 105: > >> 103: >> 104: for ex in $EXCLUDE_DIRS; do >> 105: EXCLUDE_ARGS="$EXCLUDE_ARGS --exclude=$ex " > > Thanks for your update. > This copyright should be updated too. Oh, right... I really need to write a tool that checks that before pushing... Also, I found out why this actually ever worked. There were a trailing space hidden in the assignment... ------------- PR: https://git.openjdk.java.net/jdk/pull/5276 From ihse at openjdk.java.net Fri Aug 27 13:58:10 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 27 Aug 2021 13:58:10 GMT Subject: Integrated: 8273072: Avoid using += in configure In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 10:21:26 GMT, Magnus Ihse Bursie wrote: > JDK-8272700 was created to fix a bug in a variable assignment in configure. While it fixed the bug, it kept the problematic syntax that caused the bug in the first place. > > We do not use the `FOO+="appended"` syntax for appending to variables in shell scripts, since this differs from what you'd expect (and what make produces) in that no space is added before the appended text. > > Instead, we use the longer, but clearer `FOO="$FOO appended"`. This pull request has now been integrated. Changeset: a033aa5a Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/a033aa5a3d9c63d72d11af218b9896b037fbd8de Stats: 8 lines in 4 files changed: 1 ins; 0 del; 7 mod 8273072: Avoid using += in configure Reviewed-by: dholmes, jiefu ------------- PR: https://git.openjdk.java.net/jdk/pull/5276 From ihse at openjdk.java.net Fri Aug 27 14:36:36 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 27 Aug 2021 14:36:36 GMT Subject: RFR: 8229031: Exporting CLASSPATH from shell can result in build failures Message-ID: Having the environment variable CLASSPATH set when building can cause hard-to-diagnose build errors. We should not silently accept the CLASSPATH variable when building. Normally, the classpath should be correctly setup for all invocations of java during the build. If the user wants to have a hard-coded value for CLASSPATH, they must set it explicitly in `configure`. ------------- Commit messages: - 8229031: Exporting CLASSPATH from shell can result in build failures Changes: https://git.openjdk.java.net/jdk/pull/5280/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5280&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8229031 Stats: 27 lines in 2 files changed: 27 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5280.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5280/head:pull/5280 PR: https://git.openjdk.java.net/jdk/pull/5280 From erikj at openjdk.java.net Fri Aug 27 17:35:26 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 Aug 2021 17:35:26 GMT Subject: RFR: 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info In-Reply-To: <-WksWpFVEMR7cYkJViBGXJwLNsN8z3VeRBenp1p0Na8=.45e59698-96af-4223-a4d3-786606ea2d24@github.com> References: <-WksWpFVEMR7cYkJViBGXJwLNsN8z3VeRBenp1p0Na8=.45e59698-96af-4223-a4d3-786606ea2d24@github.com> Message-ID: On Thu, 22 Jul 2021 16:43:26 GMT, Severin Gehwolf wrote: > Hi! > > Please review this tiny patch which removes the special casing of `--with-native-debug-symbols=external` for the static libs build. I don't see why this is needed. If no debug symbols are wanted `--with-native-debug-symbols=none` can be used to achieve the same effect. Therefore, I propose to remove this hunk. > > Testing: Inspecting of the log files and seeing that `-g` switch is there. Run the reproducer test on the resulting static libraries. > > Thoughts? We currently have: `--with-native-debug-symbols=internal`: Dynamic libs: debug symbols internal. Static libs: debug symbols internal `--with-native-debug-symbols=external`: Dynamic libs: debug symbols external. Static libs: No debug symbols With the suggested change: `--with-native-debug-symbols=external`: Dynamic libs: debug symbols external. Static libs: debug symbols **internal** I don't think that's a good idea. There are two important points when picking _external_. 1: that you get debug symbols, but at least equally important, 2: that debug symbols are not left around in the product bits (which are distributed). Yes, we at Oracle are indeed relying on release product bits being completely stripped and void of any debug symbols. I agree that it's clunky. We just never had a need for saving debug symbols for the static libs, so no effort was put into implementing that support. I would be ok with the patch if it instead changed to: `--with-native-debug-symbols=external`: Dynamic libs: debug symbols external. Static libs: debug symbols **external** Right now we don't have the necessary build logic implemented in NativeCompilation.gmk for moving debugsymbols to external files for static libs, so such a change would need to provide that implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4876 From erikj at openjdk.java.net Fri Aug 27 18:05:28 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 Aug 2021 18:05:28 GMT Subject: RFR: 8229031: Exporting CLASSPATH from shell can result in build failures In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 14:28:07 GMT, Magnus Ihse Bursie wrote: > Having the environment variable CLASSPATH set when building can cause hard-to-diagnose build errors. We should not silently accept the CLASSPATH variable when building. Normally, the classpath should be correctly setup for all invocations of java during the build. If the user wants to have a hard-coded value for CLASSPATH, they must set it explicitly in `configure`. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5280 From iklam at openjdk.java.net Sat Aug 28 03:05:49 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 28 Aug 2021 03:05:49 GMT Subject: RFR: 8273092: Sort classlist in JDK image Message-ID: When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. We should sort the generated classlist to make the JDK image's contents more deterministic. Tested with Mach5 tier1, tier2, builds-tier5 ------------- Commit messages: - 8273092: Sort classlist in JDK image Changes: https://git.openjdk.java.net/jdk/pull/5288/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5288&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273092 Stats: 114 lines in 3 files changed: 102 ins; 6 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5288.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5288/head:pull/5288 PR: https://git.openjdk.java.net/jdk/pull/5288 From redestad at openjdk.java.net Sat Aug 28 13:21:27 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Sat, 28 Aug 2021 13:21:27 GMT Subject: RFR: 8273092: Sort classlist in JDK image In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote: > When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image's contents more deterministic. > > Tested with Mach5 tier1, tier2, builds-tier5 Seems OK. make/jdk/src/classes/build/tools/classlist/SortClasslist.java line 31: > 29: * > 30: * The classlist is produced by adding -XX:DumpLoadedClassList=classlist > 31: */ Looks like a copy-paste error (also redundant) ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5288 From ihse at openjdk.java.net Mon Aug 30 11:40:28 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 30 Aug 2021 11:40:28 GMT Subject: RFR: 8273092: Sort classlist in JDK image In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote: > When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image's contents more deterministic. > > Tested with Mach5 tier1, tier2, builds-tier5 Looks great. Thank you for helping to make the build deterministic! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5288 From ihse at openjdk.java.net Mon Aug 30 11:41:33 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 30 Aug 2021 11:41:33 GMT Subject: Integrated: 8229031: Exporting CLASSPATH from shell can result in build failures In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 14:28:07 GMT, Magnus Ihse Bursie wrote: > Having the environment variable CLASSPATH set when building can cause hard-to-diagnose build errors. We should not silently accept the CLASSPATH variable when building. Normally, the classpath should be correctly setup for all invocations of java during the build. If the user wants to have a hard-coded value for CLASSPATH, they must set it explicitly in `configure`. This pull request has now been integrated. Changeset: 9ede41bf Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/9ede41bf894867b6d80982d7dc6ec54229a0ecb1 Stats: 27 lines in 2 files changed: 27 ins; 0 del; 0 mod 8229031: Exporting CLASSPATH from shell can result in build failures Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/5280 From dfuchs at openjdk.java.net Mon Aug 30 12:54:25 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 30 Aug 2021 12:54:25 GMT Subject: RFR: 8273092: Sort classlist in JDK image In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote: > When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image's contents more deterministic. > > Tested with Mach5 tier1, tier2, builds-tier5 make/jdk/src/classes/build/tools/classlist/SortClasslist.java line 58: > 56: String line = scanner.nextLine(); > 57: Matcher m = p.matcher(line); > 58: if (m.find()) { Are we sure that a comment line will not match this regexp, or that if it matches, it is not a comment line? ------------- PR: https://git.openjdk.java.net/jdk/pull/5288 From ihse at openjdk.java.net Mon Aug 30 13:15:46 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 30 Aug 2021 13:15:46 GMT Subject: RFR: 8270438: "Cores to use" output in configure is misleading Message-ID: Description from the bug: When building the JDK and running `configure` the output includes (example): Build performance summary: * Cores to use: 4 * Memory limit: 32768 MB The "Cores to use" value is misleading; it is not actually the number of cores specified using `--with-num-cores`, but instead the number of jobs, which (unless explicitly specified), is calculated based on the available memory and the number of cores. ------------- Commit messages: - 8270438: "Cores to use" output in configure is misleading Changes: https://git.openjdk.java.net/jdk/pull/5301/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5301&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270438 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5301/head:pull/5301 PR: https://git.openjdk.java.net/jdk/pull/5301 From magnus.ihse.bursie at oracle.com Mon Aug 30 13:17:10 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 30 Aug 2021 15:17:10 +0200 Subject: Bumping minimum GCC from 5.x to 6.x? Message-ID: <17a2fcaf-be6c-bf66-349d-b8b5a1d36b33@oracle.com> Hi all, There is an open request[1] to bump the minimum GCC version from 5 to 6. We've traditionally been very conservative with supporting old GCC versions, but GCC 6 was released in 2016 (compared to GCC 5 in 2015), and I think this sounds conservative enough. Would it create a lot of problems for anyone if we raised the minimum version? /Magnus [1] https://bugs.openjdk.java.net/browse/JDK-8256977 From erikj at openjdk.java.net Mon Aug 30 13:29:33 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 30 Aug 2021 13:29:33 GMT Subject: RFR: 8270438: "Cores to use" output in configure is misleading In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 13:06:19 GMT, Magnus Ihse Bursie wrote: > Description from the bug: > > When building the JDK and running `configure` the output includes (example): > > Build performance summary: > * Cores to use: 4 > * Memory limit: 32768 MB > > > The "Cores to use" value is misleading; it is not actually the number of cores specified using `--with-num-cores`, but instead the number of jobs, which (unless explicitly specified), is calculated based on the available memory and the number of cores. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5301 From ihse at openjdk.java.net Mon Aug 30 13:45:29 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 30 Aug 2021 13:45:29 GMT Subject: Integrated: 8270438: "Cores to use" output in configure is misleading In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 13:06:19 GMT, Magnus Ihse Bursie wrote: > Description from the bug: > > When building the JDK and running `configure` the output includes (example): > > Build performance summary: > * Cores to use: 4 > * Memory limit: 32768 MB > > > The "Cores to use" value is misleading; it is not actually the number of cores specified using `--with-num-cores`, but instead the number of jobs, which (unless explicitly specified), is calculated based on the available memory and the number of cores. This pull request has now been integrated. Changeset: fbffa54e Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/fbffa54efe447a4c911af2be1d7774a8c60d6ede Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8270438: "Cores to use" output in configure is misleading Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/5301 From iklam at openjdk.java.net Tue Aug 31 01:05:08 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 31 Aug 2021 01:05:08 GMT Subject: RFR: 8273092: Sort classlist in JDK image [v2] In-Reply-To: References: Message-ID: <9ebPG5OrKERdJyatYeoTzqkqbaIw9B2Ud61BThP6gE4=.64044a29-0cd4-49c1-9d1a-1fa313412a80@github.com> On Mon, 30 Aug 2021 12:51:43 GMT, Daniel Fuchs wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @dfuch comments > > make/jdk/src/classes/build/tools/classlist/SortClasslist.java line 58: > >> 56: String line = scanner.nextLine(); >> 57: Matcher m = p.matcher(line); >> 58: if (m.find()) { > > Are we sure that a comment line will not match this regexp, or that if it matches, it is not a comment line? Thanks for the comments. I've swapper the matching order to check for leading `#` and `@` characters first. ------------- PR: https://git.openjdk.java.net/jdk/pull/5288 From iklam at openjdk.java.net Tue Aug 31 01:05:05 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 31 Aug 2021 01:05:05 GMT Subject: RFR: 8273092: Sort classlist in JDK image [v2] In-Reply-To: References: Message-ID: > When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image's contents more deterministic. > > Tested with Mach5 tier1, tier2, builds-tier5 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dfuch comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5288/files - new: https://git.openjdk.java.net/jdk/pull/5288/files/dc170ec0..ee710895 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5288&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5288&range=00-01 Stats: 15 lines in 1 file changed: 7 ins; 7 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5288.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5288/head:pull/5288 PR: https://git.openjdk.java.net/jdk/pull/5288 From dfuchs at openjdk.java.net Tue Aug 31 09:10:30 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 31 Aug 2021 09:10:30 GMT Subject: RFR: 8273092: Sort classlist in JDK image [v2] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 01:05:05 GMT, Ioi Lam wrote: >> When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. >> >> We should sort the generated classlist to make the JDK image's contents more deterministic. >> >> Tested with Mach5 tier1, tier2, builds-tier5 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @dfuch comments Thanks Ioi! These changes look good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5288 From iklam at openjdk.java.net Tue Aug 31 16:36:33 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 31 Aug 2021 16:36:33 GMT Subject: RFR: 8273092: Sort classlist in JDK image [v2] In-Reply-To: References: Message-ID: On Sat, 28 Aug 2021 13:18:37 GMT, Claes Redestad wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @dfuch comments > > Seems OK. Thanks @cl4es @magicus @dfuch for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/5288 From iklam at openjdk.java.net Tue Aug 31 16:36:35 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 31 Aug 2021 16:36:35 GMT Subject: Integrated: 8273092: Sort classlist in JDK image In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote: > When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image's contents more deterministic. > > Tested with Mach5 tier1, tier2, builds-tier5 This pull request has now been integrated. Changeset: 1996f649 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/1996f649a3a30b7ac4b547a762417f807f5fa414 Stats: 114 lines in 3 files changed: 102 ins; 6 del; 6 mod 8273092: Sort classlist in JDK image Reviewed-by: redestad, ihse, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5288 From ralf at pkmd.de Sun Aug 29 17:40:44 2021 From: ralf at pkmd.de (R H) Date: Sun, 29 Aug 2021 19:40:44 +0200 Subject: unknown enum constant Feature.SEALED_CLASSES Message-ID: Since jdk18+7, I can not build openjdk anymore for amd64 (debian-11 and centOS 7, both with clang and gcc, plus windows-10). AARCH64 is OK, as is anything up to jdk18+6. * For target buildtools_interim_langtools_modules_java.compiler.interim__the.BUILD_java.compiler.interim_batch: warning: unknown enum constant Feature.SEALED_CLASSES warning: unknown enum constant Feature.SEALED_CLASSES error: warnings found and -Werror specified 1 error 2 warnings I always use --disable-warnings-as-errors, which seems to be ignored in this particular instance. What am I doing wrong?