From erikj at openjdk.java.net Mon Jan 4 15:32:11 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Jan 2021 15:32:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References:

Message-ID: On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [ ] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie 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 eight additional commits since the last revision: > > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - Step 2: Update references > - First stage, move actual data files Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From naoto at openjdk.java.net Tue Jan 5 18:07:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 5 Jan 2021 18:07:09 GMT Subject: [jdk16] RFR: 8259075: Update the copyright notice in the files generated by CLDR Converter tool Message-ID: Please review this copyright notice update in the CLDR Converter tool. It is now synched with src/java.base/share/legal/cldr.md file. ------------- Commit messages: - 8259075: Update the copyright notice in the files generated by CLDR Converter tool Changes: https://git.openjdk.java.net/jdk16/pull/85/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=85&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259075 Stats: 13 lines in 1 file changed: 0 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk16/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/85/head:pull/85 PR: https://git.openjdk.java.net/jdk16/pull/85 From joehw at openjdk.java.net Tue Jan 5 20:35:56 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 5 Jan 2021 20:35:56 GMT Subject: [jdk16] RFR: 8259075: Update the copyright notice in the files generated by CLDR Converter tool In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 17:59:01 GMT, Naoto Sato wrote: > Please review this copyright notice update in the CLDR Converter tool. It is now synched with src/java.base/share/legal/cldr.md file. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/85 From naoto at openjdk.java.net Wed Jan 6 16:33:59 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 6 Jan 2021 16:33:59 GMT Subject: [jdk16] Integrated: 8259075: Update the copyright notice in the files generated by CLDR Converter tool In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 17:59:01 GMT, Naoto Sato wrote: > Please review this copyright notice update in the CLDR Converter tool. It is now synched with src/java.base/share/legal/cldr.md file. This pull request has now been integrated. Changeset: 4a5786b5 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk16/commit/4a5786b5 Stats: 13 lines in 1 file changed: 0 ins; 4 del; 9 mod 8259075: Update the copyright notice in the files generated by CLDR Converter tool Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk16/pull/85 From jwilhelm at openjdk.java.net Thu Jan 7 20:45:15 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 20:45:15 GMT Subject: RFR: Merge jdk16 Message-ID: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8249633: doclint reports missing javadoc for JavaFX property methods that have a property description - 8251200: False positive messages about missing comments for serialization - 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days - 8259075: Update the copyright notice in the files generated by CLDR Converter tool - 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes - 8258558: Revert changes for JDK-8252505 and related issues - 8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition - 8259007: This test printed a blank page - 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert - ... and 8 more: https://git.openjdk.java.net/jdk/compare/0e6de4eb...bbd6426f The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1989/files Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/1989.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1989/head:pull/1989 PR: https://git.openjdk.java.net/jdk/pull/1989 From jwilhelm at openjdk.java.net Thu Jan 7 21:21:57 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 21:21:57 GMT Subject: Integrated: Merge jdk16 In-Reply-To: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> References: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> Message-ID: On Thu, 7 Jan 2021 20:40:49 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 555641ed Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/555641ed Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1989 From rriggs at openjdk.java.net Fri Jan 8 20:39:02 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 8 Jan 2021 20:39:02 GMT Subject: RFR: 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys Message-ID: Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format hexadecimal strings to use java.util.HexFormat methods. Also in tests test/jdk/java/util/Locale/SoftKeys. ------------- Commit messages: - 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys Changes: https://git.openjdk.java.net/jdk/pull/2009/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2009&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259493 Stats: 75 lines in 5 files changed: 2 ins; 63 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2009/head:pull/2009 PR: https://git.openjdk.java.net/jdk/pull/2009 From lancea at openjdk.java.net Fri Jan 8 20:43:57 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 8 Jan 2021 20:43:57 GMT Subject: RFR: 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 20:34:10 GMT, Roger Riggs wrote: > Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format hexadecimal strings to use java.util.HexFormat methods. > Also in tests test/jdk/java/util/Locale/SoftKeys. Looks good Roger. Nice cleanup. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2009 From naoto at openjdk.java.net Fri Jan 8 20:56:00 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 8 Jan 2021 20:56:00 GMT Subject: RFR: 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 20:34:10 GMT, Roger Riggs wrote: > Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format hexadecimal strings to use java.util.HexFormat methods. > Also in tests test/jdk/java/util/Locale/SoftKeys. +1 ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2009 From rriggs at openjdk.java.net Fri Jan 8 21:34:57 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 8 Jan 2021 21:34:57 GMT Subject: Integrated: 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 20:34:10 GMT, Roger Riggs wrote: > Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format hexadecimal strings to use java.util.HexFormat methods. > Also in tests test/jdk/java/util/Locale/SoftKeys. This pull request has now been integrated. Changeset: 876c7fb5 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/876c7fb5 Stats: 75 lines in 5 files changed: 2 ins; 63 del; 10 mod 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys Reviewed-by: lancea, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/2009 From herrick at openjdk.java.net Mon Jan 11 01:56:56 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 11 Jan 2021 01:56:56 GMT Subject: Withdrawn: JDK-8189198: Add "forRemoval = true" to Applet APIs In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick wrote: > JDK-8189198: Add "forRemoval = true" to Applet APIs This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1127 From serb at openjdk.java.net Mon Jan 11 08:19:19 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 11 Jan 2021 08:19:19 GMT Subject: RFR: 8259522: Apply java.io.Serial annotations in java.desktop Message-ID: Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations. This annotation can be applied to these methods in the module: private void writeObject(java.io.ObjectOutputStream stream) throws IOException private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException private void readObjectNoData() throws ObjectStreamException ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException private static final ObjectStreamField[] serialPersistentFields private static final long serialVersionUID Notes: - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification. A similar fix was implemented for java.base module as well: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html ------------- Commit messages: - Update TextAttribute.java - Update readResolve - Update writeReplace - Update readObject - Update writeObject - Update serialPersistentFields - Update serialVersionUID Changes: https://git.openjdk.java.net/jdk/pull/2020/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2020&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259522 Stats: 3426 lines in 343 files changed: 2268 ins; 287 del; 871 mod Patch: https://git.openjdk.java.net/jdk/pull/2020.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2020/head:pull/2020 PR: https://git.openjdk.java.net/jdk/pull/2020 From ihse at openjdk.java.net Mon Jan 11 09:23:11 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 09:23:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References:

Message-ID: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> On Mon, 4 Jan 2021 21:20:53 GMT, Phil Race wrote: >> Magnus Ihse Bursie 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 eight additional commits since the last revision: >> >> - Update comment refering to "make" dir >> - Move new symbols to jdk.compiler >> - Merge branch 'master' into shuffle-data >> - Move macosxicons from share to macosx >> - Move to share/data, and move jdwp.spec to java.se >> - Update references in test >> - Step 2: Update references >> - First stage, move actual data files > > Marked as reviewed by prr (Reviewer). This PR is not stale; it's just still waiting for input from @AlanBateman. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From naoto at openjdk.java.net Mon Jan 11 17:00:05 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 11 Jan 2021 17:00:05 GMT Subject: RFR: 8259528: Broken Link for [java.text.Normalizer.Form] Message-ID: Please review this simple doc fix. ------------- Commit messages: - 8259528: Broken Link for [java.text.Normalizer.Form] Changes: https://git.openjdk.java.net/jdk/pull/2028/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2028&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259528 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2028.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2028/head:pull/2028 PR: https://git.openjdk.java.net/jdk/pull/2028 From lancea at openjdk.java.net Mon Jan 11 17:06:54 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 11 Jan 2021 17:06:54 GMT Subject: RFR: 8259528: Broken Link for [java.text.Normalizer.Form] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato wrote: > Please review this simple doc fix. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2028 From joehw at openjdk.java.net Mon Jan 11 18:28:57 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 11 Jan 2021 18:28:57 GMT Subject: RFR: 8259528: Broken Link for [java.text.Normalizer.Form] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato wrote: > Please review this simple doc fix. Oops, forgot to submit the review ;-) src/java.base/share/classes/java/text/Normalizer.java line 48: > 46: * The {@code normalize} method supports the standard normalization forms > 47: * described in > 48: * This links to the latest version. Will the Normalizer always keep up with version changes? Or is it a specific version with which it complies (e.g. the latest version 13, previous 12), or is the version change irrelevant to this class? ------------- PR: https://git.openjdk.java.net/jdk/pull/2028 From iris at openjdk.java.net Mon Jan 11 19:16:57 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 11 Jan 2021 19:16:57 GMT Subject: RFR: 8259528: Broken Link for [java.text.Normalizer.Form] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato wrote: > Please review this simple doc fix. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2028 From naoto at openjdk.java.net Mon Jan 11 19:30:04 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 11 Jan 2021 19:30:04 GMT Subject: RFR: 8259528: Broken Link for [java.text.Normalizer.Form] In-Reply-To: References:

Message-ID: On Mon, 11 Jan 2021 17:35:58 GMT, Joe Wang wrote: >> Please review this simple doc fix. > > src/java.base/share/classes/java/text/Normalizer.java line 48: > >> 46: * The {@code normalize} method supports the standard normalization forms >> 47: * described in >> 48: *

Message-ID: On Tue, 12 Jan 2021 11:29:24 GMT, Alexey Ivanov wrote: >> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java >> >> Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java >> >> Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > > src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java line 42: > >> 40: */ >> 41: @Serial >> 42: private static final long serialVersionUID = 1L; > > This is the standard wording, yet should it mention the serialization is between the same versions only because the value of serialVersionUID is not unique? I think it is "quite" unique, the "1L" is used from the beginning. It is just different from the value which could be generated by the "serialver" but still should work fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/2020 From ewhelan at openjdk.java.net Tue Jan 12 20:43:56 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 12 Jan 2021 20:43:56 GMT Subject: Integrated: 8226810: Failed to launch JVM because of NullPointerException occured on System.props In-Reply-To: References: Message-ID: <_sVuvLZZf-hKgwpT624RTYuFyK10K6_-qixODalaSqs=.91781b85-f772-4106-b923-d4f4302beb97@github.com> On Tue, 12 Jan 2021 16:26:27 GMT, Evan Whelan wrote: > Hi, > > Please review this small change which enables the GB18030 charset to be built into java.base > > Thanks This pull request has now been integrated. Changeset: 5f7ccce0 Author: Evan Whelan Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/5f7ccce0 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8226810: Failed to launch JVM because of NullPointerException occured on System.props Reviewed-by: alanb, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/2053 From aivanov at openjdk.java.net Tue Jan 12 21:58:14 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 12 Jan 2021 21:58:14 GMT Subject: RFR: 8259522: Apply java.io.Serial annotations in java.desktop [v2] In-Reply-To: References:

<95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Mon, 11 Jan 2021 09:20:07 GMT, Magnus Ihse Bursie wrote: >> Marked as reviewed by prr (Reviewer). > > This PR is not stale; it's just still waiting for input from @AlanBateman. @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From naoto at openjdk.java.net Fri Jan 15 17:18:10 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 15 Jan 2021 17:18:10 GMT Subject: RFR: 8259048: (tz) Upgrade time-zone data to tzdata2020f [v2] In-Reply-To: References: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com> Message-ID: <89CktvFP3WHDhz2e7k3d67LWLV4wq7Oj1HBMwuKmxtI=.0333efae-92ec-448f-91c2-60f827f4e4b6@github.com> On Fri, 15 Jan 2021 10:24:24 GMT, Kiran Sidhartha Ravikumar wrote: >> Hi Guys, >> >> Updating the summary as tzdata2020f is available and includes tzdata2020e changes also. >> >> Please review the integration of tzdata2020f to JDK. >> >> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-December/000064.html >> Bug: https://bugs.openjdk.java.net/browse/JDK-8259048 >> >> tzdata2020e - Most of the changes are about correcting past timestamps and Australia/Currie timezone is removed. >> tzdata2020f - No changes to the data since 2020e. >> >> Regression Tests pass along with JCK. >> >> Please let me know if the changes are good to push. >> >> Thanks, >> Kiran > > Kiran Sidhartha Ravikumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - 8258878: (tz) Upgrade time-zone data to tzdata2020e > - Merge remote-tracking branch 'origin/master' into JDK-8258878 > - 8258878: (tz) Upgrade time-zone data to tzdata2020e Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1937 From mark.reinhold at oracle.com Fri Jan 15 18:27:09 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 Jan 2021 10:27:09 -0800 Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References:

<6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>

Message-ID: <20210115102709.538599954@eggemoggin.niobe.net> 2020/12/4 6:08:13 -0800, erikj at openjdk.java.net: > On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote: >>> And I can certainly move jdwp.spec to java.base instead. That's the >>> reason I need input on this: All I know is that is definitely not >>> the responsibility of the Build Group to maintain that document, and >>> I made my best guess at where to place it. >> >>> And I can certainly move jdwp.spec to java.base instead. >> >> If jdwp.spec has to move to the src tree then src/java.se is probably >> the most suitable home because Java SE specifies JDWP as an optional >> interface. So nothing to do with java.base and the build will need to >> continue to generate the sources for the front-end (jdk.jdi) and >> back-end (jdk.jdwp.agent) as they implement the protocol. > > My understanding of JEPs is that they should be viewed as living > documents. In this case, I think it's perfectly valid to update JEP > 201 with additional source code layout. Both for this and for the > other missing dirs. Feature JEPs are living documents until such time as they are delivered. In this case it would not be appropriate to update JEP 201, which is as much about the transition from the old source-code layout as it is about the new layout as of 2014. At this point, and given that we?d already gone beyond JEP 201 prior to this change (with `man` and `lib` subdirectories), what?d make the most sense is a new informational JEP that documents the source-code layout. Informational JEPs can, within reason, be updated over time. - Mark From ihse at openjdk.java.net Fri Jan 15 18:30:07 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 15 Jan 2021 18:30:07 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References:

<6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>

<20210115102709.538599954@eggemoggin.niobe.net> Message-ID: <0219364d-3926-2b7b-4cb5-90f698eeb706@oracle.com> On 2021-01-15 19:27, mark.reinhold at oracle.com wrote: > Feature JEPs are living documents until such time as they are delivered. > In this case it would not be appropriate to update JEP 201, which is as > much about the transition from the old source-code layout as it is about > the new layout as of 2014. > > At this point, and given that we?d already gone beyond JEP 201 prior to > this change (with `man` and `lib` subdirectories), what?d make the most > sense is a new informational JEP that documents the source-code layout. > Informational JEPs can, within reason, be updated over time. So I take it I need to create a new informational JEP. :-) Fine, I can do that. I assume I mostly need to extract the parts of JEP 201 that describes the (then "new") layout, update wording to show that this is a description of the current layout, and add the new additions. It'll be a very short JEP, but in this case, that's probably a virtue. /Magnus From ihse at openjdk.java.net Mon Jan 18 13:47:20 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 13:47:20 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v5] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Move characterdata templates to share/classes/java/lang. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/68b252b5..c4894348 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=03-04 Stats: 4 lines in 9 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Jan 18 13:49:49 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 13:49:49 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References:

Message-ID: <3kOn9r73AUBL0lPK7bCqaJltUETSv32UPWLRCILMwTE=.9fc7c662-7a85-41c3-a1b3-68424c062a70@github.com> On Wed, 20 Jan 2021 05:19:15 GMT, Ichiroh Takiguchi wrote: >> Hello Dmitry. >> Sorry, I should use GitHub instead of mailing list. >> I tested your fix, I saw side effect by committing preedit string. >> I'll give you detail information. > > I tried attached testcase. > import java.awt.*; > import java.awt.event.*; > > public class AWTTextTest1 extends Frame { > AWTTextTest1() { > setTitle("AWTTextTest1"); > setLayout(new GridLayout(0, 1)); > add(new TextField()); > add(new TextField()); > addWindowListener(new WindowAdapter() { > public void windowClosing(WindowEvent we) { > System.exit(0); > } > }); > setSize(400, 300); > setVisible(true); > } > public static void main(String[] args) { > new AWTTextTest1(); > } > } > 1. Start testcase > 2. Click upper TextField, turn on IME, type some character (In case of Japanese, type "aiu") > 3. Click lower TextField, preedit string is committed into lower TextField. > > Without the fix, preedit string was canceled by above operation. How do the native components work in that case like awt textarea or external apps like notepad? ------------- PR: https://git.openjdk.java.net/jdk/pull/2142 From itakiguchi at openjdk.java.net Wed Jan 20 07:37:54 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Wed, 20 Jan 2021 07:37:54 GMT Subject: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 In-Reply-To: <3kOn9r73AUBL0lPK7bCqaJltUETSv32UPWLRCILMwTE=.9fc7c662-7a85-41c3-a1b3-68424c062a70@github.com> References: <5vkJiae7XfED-16h0BOfYUm3mfa5XjjDHaynwjTXlP4=.719f91ba-393b-42dd-9395-83e8a6d7e303@github.com> <_v-sHGbrTiwy64hC1f6ljmfVRMSA6QfDBI_3WH-d0qU=.504db290-6946-42eb-9357-96da0045aecd@github.com>

<3kOn9r73AUBL0lPK7bCqaJltUETSv32UPWLRCILMwTE=.9fc7c662-7a85-41c3-a1b3-68424c062a70@github.com> Message-ID: On Wed, 20 Jan 2021 05:43:51 GMT, Sergey Bylokhov wrote: > How do the native components work in that case like awt textarea or external apps like notepad? I tested TextField+TextField, TextArea+TextArea, TextArea+TextField. Without fix: Preedit string was cancel by input focus change. With fix: Preedit string was committed into clicked component. For external application, I used Sakura Editor, because it can create 2 editor panes on one window. Preedit string was committed before moving input focus. ------------- PR: https://git.openjdk.java.net/jdk/pull/2142 From dmarkov at openjdk.java.net Wed Jan 20 10:09:49 2021 From: dmarkov at openjdk.java.net (Dmitry Markov) Date: Wed, 20 Jan 2021 10:09:49 GMT Subject: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 In-Reply-To: References: <5vkJiae7XfED-16h0BOfYUm3mfa5XjjDHaynwjTXlP4=.719f91ba-393b-42dd-9395-83e8a6d7e303@github.com> <_v-sHGbrTiwy64hC1f6ljmfVRMSA6QfDBI_3WH-d0qU=.504db290-6946-42eb-9357-96da0045aecd@github.com>

Message-ID: On Thu, 21 Jan 2021 14:54:34 GMT, Dmitry Markov wrote: >>> Now we will commit the composition string if there is an active client. That changes eliminates the issue described in JDK-8258805. Also the behaviour of AWTTextTest1 is the same as it used to be on the previous versions w/o the fix. >> >> Just to confirm: the updated behaviour is similar to what was happening in previous versions of Windows 10, that is if a compositing text isn't committed, it remains uncommitted in the text component when the focus changes instead of being committed as it was the case in the previous iteration. Is my understanding correct? > >> > Now we will commit the composition string if there is an active client. That changes eliminates the issue described in JDK-8258805. Also the behaviour of AWTTextTest1 is the same as it used to be on the previous versions w/o the fix. >> >> Just to confirm: the updated behaviour is similar to what was happening in previous versions of Windows 10, that is if a compositing text isn't committed, it remains uncommitted in the text component when the focus changes instead of being committed as it was the case in the previous iteration. Is my understanding correct? > > I am sorry but you didn't get it right. The behaviour, which was introduced in previous iteration, is still in place. It is required to get rid of the problem described in JDK-8258805 > The purpose of of the second iteration is to eliminate negative side effect (more details here https://github.com/openjdk/jdk/pull/2142#issuecomment-763340186 ) introduced by the first version of the fix. > > > Now we will commit the composition string if there is an active client. That changes eliminates the issue described in JDK-8258805. Also the behaviour of AWTTextTest1 is the same as it used to be on the previous versions w/o the fix. > > > > > > Just to confirm: the updated behaviour is similar to what was happening in previous versions of Windows 10, that is if a compositing text isn't committed, it remains uncommitted in the text component when the focus changes instead of being committed as it was the case in the previous iteration. Is my understanding correct? > > I am sorry but you didn't get it right. The behaviour, which was introduced in previous iteration, is still in place. It is required to get rid of the problem described in JDK-8258805 > The purpose of of the second iteration is to eliminate negative side effect (more details here [#2142 (comment)](https://github.com/openjdk/jdk/pull/2142#issuecomment-763340186) ) introduced by the first version of the fix. I admit I am even more confused now. To me, the description in the comment above is nearly the same as in [JBS comment](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14391025). Is the difference that the original test case disabled IME for the middle JTextField whereas in the test case above all JTextField support IME? In the updated version of the fix, we always commit the text on any focus change whether the newly focused component supports IME or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/2142 From dmarkov at openjdk.java.net Thu Jan 21 21:20:16 2021 From: dmarkov at openjdk.java.net (Dmitry Markov) Date: Thu, 21 Jan 2021 21:20:16 GMT Subject: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 In-Reply-To: References: <5vkJiae7XfED-16h0BOfYUm3mfa5XjjDHaynwjTXlP4=.719f91ba-393b-42dd-9395-83e8a6d7e303@github.com> <_v-sHGbrTiwy64hC1f6ljmfVRMSA6QfDBI_3WH-d0qU=.504db290-6946-42eb-9357-96da0045aecd@github.com> <_nz-UgmR4eQEO6OVOvgS6cP8DGUbG3a1G8Rhk33rpec=.a6e044d5-1a63-4f70-a569-714fa2a26532@github.com>

Message-ID: On Thu, 21 Jan 2021 19:25:16 GMT, Alexey Ivanov wrote: > I admit I am even more confused now. To me, the description in the comment above is nearly the same as in [JBS comment](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14391025). Is the difference that the original test case disabled IME for the middle JTextField whereas in the test case above all JTextField support IME? Well.. I think the main difference between tests is that the [test attached to the bug](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14391025) uses `JTextField` (Swing) and the [test provided above](https://github.com/openjdk/jdk/pull/2142#issuecomment-763491615) uses `TextField` (AWT). The same input method events are processed differently for Swing and AWT text components. Good example is the following test: import java.awt.*; import java.awt.event.*; public class AWTTextTest1 extends Frame { AWTTextTest1() { setTitle("AWTTextTest1"); setLayout(new GridLayout(0, 1)); add(new TextField()); add(new TextField()); addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent we) { System.exit(0); } }); setSize(400, 300); setVisible(true); } public static void main(String[] args) { new AWTTextTest1(); } } 1. Run test (originally it uses `TextField`) 2. Click upper `TextField`, turn on IME, type some character (In case of Japanese, type "aiu") 3. Click lower `TextField`, the string is canceled. 4. Replace `TextField` with `JTextField` in the test. Compile and run it again. 5. Click upper `JTextField`, turn on IME, type some character (In case of Japanese, type "aiu") 6. Click lower `JTextField`, the string is committed before focus transition. > > In the updated version of the fix, we always commit the text on any focus change whether the newly focused component supports IME or not. That?s not quite right. Actually we commit the text if the current IM client is ?active client?. For example, `JTextField` is an ?active client? but `TextField` - NOT. The status ?active client? depends on the implementation of getInputMethodRequests() method. ------------- PR: https://git.openjdk.java.net/jdk/pull/2142 From naoto at openjdk.java.net Thu Jan 21 21:40:34 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 21 Jan 2021 21:40:34 GMT Subject: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 In-Reply-To: References: <5vkJiae7XfED-16h0BOfYUm3mfa5XjjDHaynwjTXlP4=.719f91ba-393b-42dd-9395-83e8a6d7e303@github.com> <_v-sHGbrTiwy64hC1f6ljmfVRMSA6QfDBI_3WH-d0qU=.504db290-6946-42eb-9357-96da0045aecd@github.com> <_nz-UgmR4eQEO6OVOvgS6cP8DGUbG3a1G8Rhk33rpec=.a6e044d5-1a63-4f70-a569-714fa2a26532@github.com>

Message-ID: <1Uo8oYEcWZr3EhGB8icHlJD55-ompLu0u_PgFBx1nWk=.36bfbee7-3a15-4559-b877-fb8126bf9bad@github.com> On Thu, 21 Jan 2021 21:17:53 GMT, Dmitry Markov wrote: >>> > > Now we will commit the composition string if there is an active client. That changes eliminates the issue described in JDK-8258805. Also the behaviour of AWTTextTest1 is the same as it used to be on the previous versions w/o the fix. >>> > >>> > >>> > Just to confirm: the updated behaviour is similar to what was happening in previous versions of Windows 10, that is if a compositing text isn't committed, it remains uncommitted in the text component when the focus changes instead of being committed as it was the case in the previous iteration. Is my understanding correct? >>> >>> I am sorry but you didn't get it right. The behaviour, which was introduced in previous iteration, is still in place. It is required to get rid of the problem described in JDK-8258805 >>> The purpose of of the second iteration is to eliminate negative side effect (more details here [#2142 (comment)](https://github.com/openjdk/jdk/pull/2142#issuecomment-763340186) ) introduced by the first version of the fix. >> >> I admit I am even more confused now. To me, the description in the comment above is nearly the same as in [JBS comment](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14391025). Is the difference that the original test case disabled IME for the middle JTextField whereas in the test case above all JTextField support IME? >> >> In the updated version of the fix, we always commit the text on any focus change whether the newly focused component supports IME or not. > >> I admit I am even more confused now. To me, the description in the comment above is nearly the same as in [JBS comment](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14391025). Is the difference that the original test case disabled IME for the middle JTextField whereas in the test case above all JTextField support IME? > > Well.. I think the main difference between tests is that the [test attached to the bug](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14391025) uses `JTextField` (Swing) and the [test provided above](https://github.com/openjdk/jdk/pull/2142#issuecomment-763491615) uses `TextField` (AWT). The same input method events are processed differently for Swing and AWT text components. Good example is the following test: > > import java.awt.*; > import java.awt.event.*; > > public class AWTTextTest1 extends Frame { > AWTTextTest1() { > setTitle("AWTTextTest1"); > setLayout(new GridLayout(0, 1)); > add(new TextField()); > add(new TextField()); > addWindowListener(new WindowAdapter() { > public void windowClosing(WindowEvent we) { > System.exit(0); > } > }); > setSize(400, 300); > setVisible(true); > } > public static void main(String[] args) { > new AWTTextTest1(); > } > } > > 1. Run test (originally it uses `TextField`) > 2. Click upper `TextField`, turn on IME, type some character (In case of Japanese, type "aiu") > 3. Click lower `TextField`, the string is canceled. > 4. Replace `TextField` with `JTextField` in the test. Compile and run it again. > 5. Click upper `JTextField`, turn on IME, type some character (In case of Japanese, type "aiu") > 6. Click lower `JTextField`, the string is committed before focus transition. > >> >> In the updated version of the fix, we always commit the text on any focus change whether the newly focused component supports IME or not. > > That?s not quite right. Actually we commit the text if the current IM client is ?active client?. For example, `JTextField` is an ?active client? but `TextField` - NOT. The status ?active client? depends on the implementation of getInputMethodRequests() method. Hi, AWT's `TextComponent` is a `peered` input client, and Swing's `JTextComponent` is an `active` input client. Thus it is OK to behave differently. I would expect that AWT's one behaves as the same as native Windows apps, and Swing's one should commit text into the component that has lost the focus. ------------- PR: https://git.openjdk.java.net/jdk/pull/2142 From aivanov at openjdk.java.net Thu Jan 21 21:40:32 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 21 Jan 2021 21:40:32 GMT Subject: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 [v2] In-Reply-To: References: <5vkJiae7XfED-16h0BOfYUm3mfa5XjjDHaynwjTXlP4=.719f91ba-393b-42dd-9395-83e8a6d7e303@github.com> Message-ID: On Thu, 21 Jan 2021 13:51:58 GMT, Dmitry Markov wrote: >> Problem description: >> The IME behaviour has changed starting from recent Windows 10 builds. In particular if the complex characters (Japanese, Chinese, etc.) are entered to some component and the focus is transferred to another component (which does not support the IM) the IM is disabled and the unconfirmed composition string gets discarded. >> On previous Windows versions in the same situation the composition string is not discarded. >> >> Fix: >> It is necessary to take care of unconfirmed composition string once the IME is going to be disabled. >> >> Testing: >> All our automated regression and JCK tests passed with the proposed change. > > Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision: > > Use endComposition() instead of endCompositionNative() Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2142 From dmarkov at openjdk.java.net Thu Jan 21 21:46:45 2021 From: dmarkov at openjdk.java.net (Dmitry Markov) Date: Thu, 21 Jan 2021 21:46:45 GMT Subject: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 [v2] In-Reply-To: References: <5vkJiae7XfED-16h0BOfYUm3mfa5XjjDHaynwjTXlP4=.719f91ba-393b-42dd-9395-83e8a6d7e303@github.com>

Message-ID: On Thu, 21 Jan 2021 21:34:25 GMT, Alexey Ivanov wrote: >> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision: >> >> Use endComposition() instead of endCompositionNative() > > Marked as reviewed by aivanov (Reviewer). > Hi, > > AWT's `TextComponent` is a `peered` input client, and Swing's `JTextComponent` is an `active` input client. Thus it is OK to behave differently. I would expect that AWT's one behaves as the same as native Windows apps, and Swing's one should commit text into the component that has lost the focus. Thank you for confirmation! With the fix we have the same behaviour as you described. ------------- PR: https://git.openjdk.java.net/jdk/pull/2142 From smarks at openjdk.java.net Fri Jan 22 05:54:20 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 22 Jan 2021 05:54:20 GMT Subject: RFR: 8246788: ZoneRules invariants can be broken Message-ID: Tighten up argument checking in constructor. ------------- Commit messages: - 8246788: ZoneRules invariants can be broken Changes: https://git.openjdk.java.net/jdk/pull/2191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2191&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246788 Stats: 90 lines in 2 files changed: 87 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2191/head:pull/2191 PR: https://git.openjdk.java.net/jdk/pull/2191 From itakiguchi at openjdk.java.net Fri Jan 22 08:16:46 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Fri, 22 Jan 2021 08:16:46 GMT Subject: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 [v2] In-Reply-To: References: <5vkJiae7XfED-16h0BOfYUm3mfa5XjjDHaynwjTXlP4=.719f91ba-393b-42dd-9395-83e8a6d7e303@github.com>

Message-ID: On Thu, 21 Jan 2021 21:41:09 GMT, Dmitry Markov wrote: >> Marked as reviewed by aivanov (Reviewer). > >> Hi, >> >> AWT's `TextComponent` is a `peered` input client, and Swing's `JTextComponent` is an `active` input client. Thus it is OK to behave differently. I would expect that AWT's one behaves as the same as native Windows apps, and Swing's one should commit text into the component that has lost the focus. > > Thank you for confirmation! With the fix we have the same behaviour as you described. Thanks, Dmitry. I tested your new fix. It's fine now on Swing and AWT. ------------- PR: https://git.openjdk.java.net/jdk/pull/2142 From rriggs at openjdk.java.net Fri Jan 22 14:44:38 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 22 Jan 2021 14:44:38 GMT Subject: RFR: 8246788: ZoneRules invariants can be broken In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 05:39:55 GMT, Stuart Marks wrote: > Tighten up argument checking in constructor. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2191 From dfuchs at openjdk.java.net Fri Jan 22 14:50:56 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 22 Jan 2021 14:50:56 GMT Subject: RFR: 8246788: ZoneRules invariants can be broken In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 05:39:55 GMT, Stuart Marks wrote: > Tighten up argument checking in constructor. src/java.base/share/classes/java/time/zone/ZoneRules.java line 263: > 261: // last rules > 262: Object[] temp = lastRules.toArray(); > 263: ZoneOffsetTransitionRule[] rulesArray = Arrays.copyOf(temp, temp.length, ZoneOffsetTransitionRule[].class); LGTM. Could be replaced by: ZoneOffsetTransitionRule[] rulesArray = (ZoneOffsetTransitionRule[])lastRules.toArray(new ZoneOffsetTransitionRule[0]).clone(); if you wanted - but what you currently have is good for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2191 From naoto at openjdk.java.net Fri Jan 22 16:55:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 22 Jan 2021 16:55:40 GMT Subject: RFR: 8246788: ZoneRules invariants can be broken In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 05:39:55 GMT, Stuart Marks wrote: > Tighten up argument checking in constructor. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2191 From github.com+592810+efge at openjdk.java.net Fri Jan 22 17:09:48 2021 From: github.com+592810+efge at openjdk.java.net (Florent Guillaume) Date: Fri, 22 Jan 2021 17:09:48 GMT Subject: RFR: 8246788: ZoneRules invariants can be broken In-Reply-To: References:

Message-ID: On Fri, 22 Jan 2021 14:48:00 GMT, Daniel Fuchs wrote: >> Tighten up argument checking in constructor. > > src/java.base/share/classes/java/time/zone/ZoneRules.java line 263: > >> 261: // last rules >> 262: Object[] temp = lastRules.toArray(); >> 263: ZoneOffsetTransitionRule[] rulesArray = Arrays.copyOf(temp, temp.length, ZoneOffsetTransitionRule[].class); > > LGTM. Could be replaced by: > > ZoneOffsetTransitionRule[] rulesArray = (ZoneOffsetTransitionRule[])lastRules.toArray(new ZoneOffsetTransitionRule[0]).clone(); > > if you wanted - but what you currently have is good for me. Or even maybe `rulesArray = lastRules.toArray(ZoneOffsetTransitionRule[]::new);`? ------------- PR: https://git.openjdk.java.net/jdk/pull/2191 From dfuchs at openjdk.java.net Fri Jan 22 17:15:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 22 Jan 2021 17:15:40 GMT Subject: RFR: 8246788: ZoneRules invariants can be broken In-Reply-To: References:

Message-ID: On Fri, 22 Jan 2021 17:12:34 GMT, Daniel Fuchs wrote: >> Or even maybe `rulesArray = lastRules.toArray(ZoneOffsetTransitionRule[]::new);`? > > Good point - but that would be: > > ZoneOffsetTransitionRule[] rulesArray = lastRules.toArray(ZoneOffsetTransitionRule[]::new).clone(); Interesting. This last one is more concise, but it's a bit harder to reason about. The lastRules implementation could return an array of a type other than ZOTR[]. If it's unrelated or a supertype, this would result in ClassCastException -- probably not a problem. If it were a subtype of ZOTR[], this would get stored in the object's field. Is this a problem? Turns out it can't happen, since ZOTR is final. While not wrong, I don't think this is the right idiom. It occurs to me that there should by another overload Arrays.copyOf(array, newType) that changes the type without changing the length. This would let us get rid of the local variable. ------------- PR: https://git.openjdk.java.net/jdk/pull/2191 From dmarkov at openjdk.java.net Fri Jan 22 20:00:54 2021 From: dmarkov at openjdk.java.net (Dmitry Markov) Date: Fri, 22 Jan 2021 20:00:54 GMT Subject: Integrated: 8258805: Japanese characters not entered by mouse click on Windows 10 In-Reply-To: <5vkJiae7XfED-16h0BOfYUm3mfa5XjjDHaynwjTXlP4=.719f91ba-393b-42dd-9395-83e8a6d7e303@github.com> References: <5vkJiae7XfED-16h0BOfYUm3mfa5XjjDHaynwjTXlP4=.719f91ba-393b-42dd-9395-83e8a6d7e303@github.com> Message-ID: On Tue, 19 Jan 2021 11:10:35 GMT, Dmitry Markov wrote: > Problem description: > The IME behaviour has changed starting from recent Windows 10 builds. In particular if the complex characters (Japanese, Chinese, etc.) are entered to some component and the focus is transferred to another component (which does not support the IM) the IM is disabled and the unconfirmed composition string gets discarded. > On previous Windows versions in the same situation the composition string is not discarded. > > Fix: > It is necessary to take care of unconfirmed composition string once the IME is going to be disabled. > > Testing: > All our automated regression and JCK tests passed with the proposed change. This pull request has now been integrated. Changeset: 53fecba7 Author: Dmitry Markov URL: https://git.openjdk.java.net/jdk/commit/53fecba7 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8258805: Japanese characters not entered by mouse click on Windows 10 Reviewed-by: aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/2142 From alanb at openjdk.java.net Sat Jan 23 07:57:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 23 Jan 2021 07:57:43 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References:

<95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>