From naoto at openjdk.org Fri Jul 1 16:09:53 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 1 Jul 2022 16:09:53 GMT Subject: [jdk19] Integrated: 8289549: ISO 4217 Amendment 172 Update In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 22:05:38 GMT, Naoto Sato wrote: > Trivial fix to currency data files. The change was only made to its amendment number, as the new Sierra Leone currency has already been active with amendment 171. This pull request has now been integrated. Changeset: 604ea90d Author: Naoto Sato URL: https://git.openjdk.org/jdk19/commit/604ea90d55ac8354fd7287490ef59b8e3ce020d1 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8289549: ISO 4217 Amendment 172 Update Reviewed-by: iris ------------- PR: https://git.openjdk.org/jdk19/pull/96 From jwilhelm at openjdk.org Sat Jul 2 11:15:24 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sat, 2 Jul 2022 11:15:24 GMT Subject: RFR: Merge jdk19 Message-ID: Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8245268: -Xcomp is missing from java launcher documentation - 8288703: GetThreadState returns 0 for virtual thread that has terminated - 8288854: getLocalGraphicsEnvironment() on for multi-screen setups throws exception NPE - 8280320: C2: Loop opts are missing during OSR compilation - 8289570: SegmentAllocator:allocateUtf8String(String str) default behavior mismatch to spec - 8289585: ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64 - 8289549: ISO 4217 Amendment 172 Update - 8284358: Unreachable loop is not removed from C2 IR, leading to a broken graph The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9354&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9354&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9354/files Stats: 382 lines in 14 files changed: 330 ins; 5 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/9354.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9354/head:pull/9354 PR: https://git.openjdk.org/jdk/pull/9354 From jwilhelm at openjdk.org Sat Jul 2 18:13:28 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sat, 2 Jul 2022 18:13:28 GMT Subject: RFR: Merge jdk19 [v2] In-Reply-To: References: Message-ID: <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com> > Forwardport JDK 19 -> JDK 20 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8289603: Code change for JDK-8170762 breaks all build Reviewed-by: weijun - 8170762: Document that ISO10126Padding pads with random bytes Reviewed-by: weijun - 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB Reviewed-by: alanb - 8289257: Some custom loader tests failed due to symbol refcount not decremented Reviewed-by: iklam, coleenp - 8289534: Change 'uncomplicated' hotspot runtime options Reviewed-by: coleenp, dholmes - 8289512: Fix GCC 12 warnings for adlc output_c.cpp Reviewed-by: kvn, lucy - 8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in TypeAryPtr::dump2 with -XX:+TracePhaseCCP Reviewed-by: kvn, thartmann, chagedorn, dlong - 8288444: Remove the workaround for frame.pack() in ModalDialogTest Reviewed-by: azvegint - 8289434: x86_64: Improve comment on gen_continuation_enter() Reviewed-by: kvn - ... and 189 more: https://git.openjdk.org/jdk/compare/f5cdabad...20b15114 ------------- Changes: https://git.openjdk.org/jdk/pull/9354/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9354&range=01 Stats: 79992 lines in 1361 files changed: 50048 ins; 16523 del; 13421 mod Patch: https://git.openjdk.org/jdk/pull/9354.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9354/head:pull/9354 PR: https://git.openjdk.org/jdk/pull/9354 From jwilhelm at openjdk.org Sat Jul 2 18:13:29 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sat, 2 Jul 2022 18:13:29 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Sat, 2 Jul 2022 11:03:38 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 70f56933 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/70f5693356277c0685668219a79819707d099d9f Stats: 382 lines in 14 files changed: 330 ins; 5 del; 47 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9354 From duke at openjdk.org Sat Jul 2 18:42:04 2022 From: duke at openjdk.org (kristylee88) Date: Sat, 2 Jul 2022 18:42:04 GMT Subject: RFR: Merge jdk19 [v2] In-Reply-To: <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com> References: <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com> Message-ID: On Sat, 2 Jul 2022 18:13:28 GMT, Jesper Wilhelmsson wrote: >> Forwardport JDK 19 -> JDK 20 > > Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits: > > - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 > - 8289603: Code change for JDK-8170762 breaks all build > > Reviewed-by: weijun > - 8170762: Document that ISO10126Padding pads with random bytes > > Reviewed-by: weijun > - 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB > > Reviewed-by: alanb > - 8289257: Some custom loader tests failed due to symbol refcount not decremented > > Reviewed-by: iklam, coleenp > - 8289534: Change 'uncomplicated' hotspot runtime options > > Reviewed-by: coleenp, dholmes > - 8289512: Fix GCC 12 warnings for adlc output_c.cpp > > Reviewed-by: kvn, lucy > - 8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in TypeAryPtr::dump2 with -XX:+TracePhaseCCP > > Reviewed-by: kvn, thartmann, chagedorn, dlong > - 8288444: Remove the workaround for frame.pack() in ModalDialogTest > > Reviewed-by: azvegint > - 8289434: x86_64: Improve comment on gen_continuation_enter() > > Reviewed-by: kvn > - ... and 189 more: https://git.openjdk.org/jdk/compare/f5cdabad...20b15114 Marked as reviewed by kristylee88 at github.com (no known OpenJDK username). Marked as reviewed by kristylee88 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/9354 From attila at openjdk.org Sun Jul 3 19:51:22 2022 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 3 Jul 2022 19:51:22 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: <4OCN70Oq_ohbWdZwrI4DjJPBOU13KGbXdz3-rhLR3_k=.25ee110e-32df-48e8-b5b3-1f65e93a9353@github.com> On Wed, 22 Jun 2022 21:29:50 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time > use computeIfAbsent where lambda could be short and static Few more thoughts. src/java.base/share/classes/java/time/ZoneOffset.java line 435: > 433: result = prev; > 434: } > 435: ID_CACHE.putIfAbsent(result.getId(), result); Feel free to ignore this one, but you could still have this be a `computeIfAbsent` and put the ID_CACHE.putIfAbsent part in the lambda. Yeah, there'll be more work done inside of `computeIfAbsent` but I think it's an acceptable tradeoff for a more comprehensible code. src/java.base/share/classes/java/time/format/DecimalStyle.java line 163: > 161: public static DecimalStyle of(Locale locale) { > 162: Objects.requireNonNull(locale, "locale"); > 163: return CACHE.computeIfAbsent(locale, l -> create(l)); Suggestion: return CACHE.computeIfAbsent(locale, DecimalStyle::create); ------------- Changes requested by attila (Reviewer). PR: https://git.openjdk.org/jdk/pull/9208 From attila at openjdk.org Sun Jul 3 19:51:23 2022 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 3 Jul 2022 19:51:23 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Tue, 28 Jun 2022 07:27:30 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/time/temporal/WeekFields.java line 331: >> >>> 329: String key = firstDayOfWeek.toString() + minimalDaysInFirstWeek; >>> 330: WeekFields rules = CACHE.get(key); >>> 331: if (rules == null) { >> >> Perhaps you don't even need this `if` block and the preceding `CACHE.get(key)` and maybe it can be replaced with: >> >> >> return CACHE.computeIfAbsent(key, ignore -> new WeekFields(firstDayOfWeek, minimalDaysInFirstWeek)); > > But it will generate garbage: non-static lambda. It already generates some garbage as it does string concatenation for the key. Here's an idea: declare a record class for the key, `record CacheKey(DayOfWeek firstDayOfWeek, int minimalDaysInFirstWeek)`. It will be more efficient than using strings for keys, and then you can have a static lambda. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From duke at openjdk.org Sun Jul 3 20:49:42 2022 From: duke at openjdk.org (liach) Date: Sun, 3 Jul 2022 20:49:42 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Wed, 22 Jun 2022 21:29:50 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time > use computeIfAbsent where lambda could be short and static src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 312: > 310: private Object findStore(TemporalField field, Locale locale) { > 311: Entry key = createEntry(field, locale); > 312: return CACHE.computeIfAbsent(key, e -> createStore(e.getKey(), e.getValue())); If `createStore` can be static, the call site will only have to construct a constant lambda than having to pass `this` to construct a new instance on every call ------------- PR: https://git.openjdk.org/jdk/pull/9208 From attila at openjdk.org Sun Jul 3 22:10:26 2022 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 3 Jul 2022 22:10:26 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Sun, 3 Jul 2022 20:42:53 GMT, liach wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8288723: Avoid redundant ConcurrentHashMap.get call in java.time >> use computeIfAbsent where lambda could be short and static > > src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 312: > >> 310: private Object findStore(TemporalField field, Locale locale) { >> 311: Entry key = createEntry(field, locale); >> 312: return CACHE.computeIfAbsent(key, e -> createStore(e.getKey(), e.getValue())); > > If `createStore` can be static, the call site will only have to construct a constant lambda than having to pass `this` to construct a new instance on every call Well, if you _really_ want to noodle this for performance, you can also store a `this`-bound lambda in a `private final` instance field, so then it's only created once too. I wouldn't put it past `javac` to do this, but I'd have to disassemble the bytecode of a little test program to see whether it's the case. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Mon Jul 4 07:06:30 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 07:06:30 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v3] In-Reply-To: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: > Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9208/files - new: https://git.openjdk.org/jdk/pull/9208/files/aa67cdf6..70223b4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9208&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9208&range=01-02 Stats: 22 lines in 3 files changed: 0 ins; 11 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/9208.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9208/head:pull/9208 PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Mon Jul 4 07:06:30 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 07:06:30 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v3] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: <2-UjojGQKHkUzJad-eZ-p0Nc_6Em8lj-Jf2sKrm-95c=.08e39048-6ef3-4b7d-9258-3870baecf803@github.com> On Tue, 21 Jun 2022 17:08:17 GMT, liach wrote: >> @liach advance apologies for nitpicking: `ConcurrentHashMap` doesn't in general block while the mapping function runs. It can block _some_ concurrent updates, namely those that [hash to the same bin](https://github.com/openjdk/jdk/blob/0f801fe6fd2fcc181121f9846f6869ca3a03e18a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L324) and it won't block concurrent reads. I'm not saying the concern you raised isn't valid, just wanted to clarify that the situation is not nearly as grave as overall blocking; after all it ain't a `Collections.synchronizedMap` :-) > > Yeah, since `putIfAbsent` may block `get` calls, the blocking of `computeIfAbsent` is minuscule as long as the creation code is efficient enough. Just be careful that when writing the lambda for `computeIfAbsent`, preferably write static lambdas (that doesn't use `this`, instances, or local variables) so that one lambda can be reused over time than having to create a new one on each invocation. Updated ------------- PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Mon Jul 4 07:06:30 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 07:06:30 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Sun, 3 Jul 2022 19:44:55 GMT, Attila Szegedi wrote: >> But it will generate garbage: non-static lambda. > > It already generates some garbage as it does string concatenation for the key. Here's an idea: declare a record class for the key, `record CacheKey(DayOfWeek firstDayOfWeek, int minimalDaysInFirstWeek)`. It will be more efficient than using strings for keys, and then you can have a static lambda. done ------------- PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Mon Jul 4 20:25:46 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 20:25:46 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: <4OCN70Oq_ohbWdZwrI4DjJPBOU13KGbXdz3-rhLR3_k=.25ee110e-32df-48e8-b5b3-1f65e93a9353@github.com> References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> <4OCN70Oq_ohbWdZwrI4DjJPBOU13KGbXdz3-rhLR3_k=.25ee110e-32df-48e8-b5b3-1f65e93a9353@github.com> Message-ID: On Sun, 3 Jul 2022 19:47:16 GMT, Attila Szegedi wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8288723: Avoid redundant ConcurrentHashMap.get call in java.time >> use computeIfAbsent where lambda could be short and static > > src/java.base/share/classes/java/time/ZoneOffset.java line 435: > >> 433: result = prev; >> 434: } >> 435: ID_CACHE.putIfAbsent(result.getId(), result); > > Feel free to ignore this one, but you could still have this be a `computeIfAbsent` and put the ID_CACHE.putIfAbsent part in the lambda. Yeah, there'll be more work done inside of `computeIfAbsent` but I think it's an acceptable tradeoff for a more comprehensible code. Implemented ------------- PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Mon Jul 4 20:33:14 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 20:33:14 GMT Subject: RFR: 8289706: (cs) Avoid redundant TreeMap.containsKey call in AbstractCharsetProvider Message-ID: The method `sun.nio.cs.ext.AbstractCharsetProvider#put` is effectively equivalent of `Map.putIfAbsent` call. https://github.com/openjdk/jdk/blob/df063f7db18a40ea7325fe608b3206a6dff812c1/src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java#L81-L84 Instead of hand-written method we can use `putIfAbsent` directly. I makes code cleaner and gives a bit of performance. ------------- Commit messages: - [PATCH] Avoid redundant TreeMap.containsKey call in AbstractCharsetProvider Changes: https://git.openjdk.org/jdk/pull/8483/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8483&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289706 Stats: 13 lines in 1 file changed: 0 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/8483.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8483/head:pull/8483 PR: https://git.openjdk.org/jdk/pull/8483 From attila at openjdk.org Mon Jul 4 20:33:15 2022 From: attila at openjdk.org (Attila Szegedi) Date: Mon, 4 Jul 2022 20:33:15 GMT Subject: RFR: 8289706: (cs) Avoid redundant TreeMap.containsKey call in AbstractCharsetProvider In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 09:45:07 GMT, Andrey Turbanov wrote: > The method `sun.nio.cs.ext.AbstractCharsetProvider#put` is effectively equivalent of `Map.putIfAbsent` call. > > https://github.com/openjdk/jdk/blob/df063f7db18a40ea7325fe608b3206a6dff812c1/src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java#L81-L84 > > Instead of hand-written method we can use `putIfAbsent` directly. > I makes code cleaner and gives a bit of performance. Marked as reviewed by attila (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/8483 From rriggs at openjdk.org Tue Jul 5 15:29:42 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Jul 2022 15:29:42 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Sun, 3 Jul 2022 22:06:58 GMT, Attila Szegedi wrote: >> src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 312: >> >>> 310: private Object findStore(TemporalField field, Locale locale) { >>> 311: Entry key = createEntry(field, locale); >>> 312: return CACHE.computeIfAbsent(key, e -> createStore(e.getKey(), e.getValue())); >> >> If `createStore` can be static, the call site will only have to construct a constant lambda than having to pass `this` to construct a new instance on every call > > Well, if you _really_ want to noodle this for performance, you can also store a `this`-bound lambda in a `private final` instance field, so then it's only created once too. I wouldn't put it past `javac` to do this, but I'd have to disassemble the bytecode of a little test program to see whether it's the case. Can there be some JMH tests to confirm the performance? The value domain of the keys is pretty limited (7 * 7) max; and I'm not sure that the combination of creating a new record and the hashcode and equals methods would be faster than string concat of a constant and a single digit integer. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From naoto at openjdk.org Tue Jul 5 16:39:32 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 5 Jul 2022 16:39:32 GMT Subject: RFR: 8289706: (cs) Avoid redundant TreeMap.containsKey call in AbstractCharsetProvider In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 09:45:07 GMT, Andrey Turbanov wrote: > The method `sun.nio.cs.ext.AbstractCharsetProvider#put` is effectively equivalent of `Map.putIfAbsent` call. > > https://github.com/openjdk/jdk/blob/df063f7db18a40ea7325fe608b3206a6dff812c1/src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java#L81-L84 > > Instead of hand-written method we can use `putIfAbsent` directly. > I makes code cleaner and gives a bit of performance. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/8483 From djelinski at openjdk.org Tue Jul 5 21:06:58 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 5 Jul 2022 21:06:58 GMT Subject: RFR: 8289768: Clean up unused code Message-ID: This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. ------------- Commit messages: - Remove unused variables (windows) - Remove unused variables (macos) - Remove unused variables (linux) Changes: https://git.openjdk.org/jdk/pull/9383/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289768 Stats: 69 lines in 45 files changed: 0 ins; 65 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From aturbanov at openjdk.org Tue Jul 5 20:53:42 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 5 Jul 2022 20:53:42 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Tue, 5 Jul 2022 15:26:06 GMT, Roger Riggs wrote: >> Well, if you _really_ want to noodle this for performance, you can also store a `this`-bound lambda in a `private final` instance field, so then it's only created once too. I wouldn't put it past `javac` to do this, but I'd have to disassemble the bytecode of a little test program to see whether it's the case. > > Can there be some JMH tests to confirm the performance? > The value domain of the keys is pretty limited (7 * 7) max; and I'm not sure that the combination of creating a new record and the hashcode and equals methods would be faster than string concat of a constant and a single digit integer. @RogerRiggs is you comment about `DateTimeTextProvider.findStore` or `WeekFields.of`? There is no record creation here, in `DateTimeTextProvider.findStore`. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From attila at openjdk.org Tue Jul 5 21:30:30 2022 From: attila at openjdk.org (Attila Szegedi) Date: Tue, 5 Jul 2022 21:30:30 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: <6vhuyCUEh-vPPge9hMbzMfAlKQ7bqKSxAMgScEkCAtE=.9202220b-4c2f-4d28-96a5-c6328fd54f53@github.com> On Tue, 5 Jul 2022 15:26:06 GMT, Roger Riggs wrote: >> Well, if you _really_ want to noodle this for performance, you can also store a `this`-bound lambda in a `private final` instance field, so then it's only created once too. I wouldn't put it past `javac` to do this, but I'd have to disassemble the bytecode of a little test program to see whether it's the case. > > Can there be some JMH tests to confirm the performance? > The value domain of the keys is pretty limited (7 * 7) max; and I'm not sure that the combination of creating a new record and the hashcode and equals methods would be faster than string concat of a constant and a single digit integer. @RogerRiggs in my view, it's not about performance per se??I'll sometimes help along these kinds of small fix PRs (that are more likely than not driven by IntelliJ code refactoring suggestions) if I think they lead to more idiomatic code in the JDK with no drawbacks. I think there's value in periodically revisiting existing code and improve it to use new language and library construct that have become available since ? people study JDK source code, and I think it's important they see as good examples in there as possible. I do like seeing an old example of hand-rolled compute-if-absent being replaced by an actual `computeIfAbsent` call. Similarly, I think using records as composite keys is in general a better practice over simulating a composite key by creating a string representation of it. Yeah, it'll load additional code at runtime for that record's class, and yes, I'm aware records' `hashCode`/`equals`/`toString` are implemented by delegating to factory methods that heavily use method handle combinators. If records are meant as lightweight value-semantics composites, it should be okay to use them like this and if there are performance concerns with their use, then those concerns should be addressed by improving their performance. OTOH, MH combinators installed into constant call sites are well optimized by HotSpot these days??anyhow, a discussion for another day. In this specific instance, the value domain of the keys is limited, but the number of method calls to `WeekFields.of` isn't. It could be benchmarked but if there's concerns, it's also okay to de-scope the record-as-key from this PR. I don't have strong feelings either way. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Wed Jul 6 06:43:31 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 6 Jul 2022 06:43:31 GMT Subject: Integrated: 8289706: (cs) Avoid redundant TreeMap.containsKey call in AbstractCharsetProvider In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 09:45:07 GMT, Andrey Turbanov wrote: > The method `sun.nio.cs.ext.AbstractCharsetProvider#put` is effectively equivalent of `Map.putIfAbsent` call. > > https://github.com/openjdk/jdk/blob/df063f7db18a40ea7325fe608b3206a6dff812c1/src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java#L81-L84 > > Instead of hand-written method we can use `putIfAbsent` directly. > I makes code cleaner and gives a bit of performance. This pull request has now been integrated. Changeset: f783244c Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/f783244caf041b6f79036dfcf29ff857d9c1c78f Stats: 13 lines in 1 file changed: 0 ins; 9 del; 4 mod 8289706: (cs) Avoid redundant TreeMap.containsKey call in AbstractCharsetProvider Reviewed-by: attila, naoto ------------- PR: https://git.openjdk.org/jdk/pull/8483 From lancea at openjdk.org Wed Jul 6 15:35:39 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 6 Jul 2022 15:35:39 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) zlib looks fine given it is openjdk and not an upstream needed change ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From rriggs at openjdk.org Wed Jul 6 14:15:39 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Jul 2022 14:15:39 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: <6vhuyCUEh-vPPge9hMbzMfAlKQ7bqKSxAMgScEkCAtE=.9202220b-4c2f-4d28-96a5-c6328fd54f53@github.com> References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> <6vhuyCUEh-vPPge9hMbzMfAlKQ7bqKSxAMgScEkCAtE=.9202220b-4c2f-4d28-96a5-c6328fd54f53@github.com> Message-ID: On Tue, 5 Jul 2022 21:27:16 GMT, Attila Szegedi wrote: >> Can there be some JMH tests to confirm the performance? >> The value domain of the keys is pretty limited (7 * 7) max; and I'm not sure that the combination of creating a new record and the hashcode and equals methods would be faster than string concat of a constant and a single digit integer. > > @RogerRiggs in my view, it's not about performance per se??I'll sometimes help along these kinds of small fix PRs (that are more likely than not driven by IntelliJ code refactoring suggestions) if I think they lead to more idiomatic code in the JDK with no drawbacks. I think there's value in periodically revisiting existing code and improve it to use new language and library construct that have become available since ? people study JDK source code, and I think it's important they see as good examples in there as possible. I do like seeing an old example of hand-rolled compute-if-absent being replaced by an actual `computeIfAbsent` call. Similarly, I think using records as composite keys is in general a better practice over simulating a composite key by creating a string representation of it. > > Yeah, it'll load additional code at runtime for that record's class, and yes, I'm aware records' `hashCode`/`equals`/`toString` are implemented by delegating to factory methods that heavily use method handle combinators. If records are meant as lightweight value-semantics composites, it should be okay to use them like this and if there are performance concerns with their use, then those concerns should be addressed by improving their performance. OTOH, MH combinators installed into constant call sites are well optimized by HotSpot these days??anyhow, a discussion for another day. > > In this specific instance, the value domain of the keys is limited, but the number of method calls to `WeekFields.of` isn't. It could be benchmarked but if there's concerns, it's also okay to de-scope the record-as-key from this PR. I don't have strong feelings either way. The comment was about WeekFields.of(), I misplaced the comment. @szegedi All good points about modernizing code... One of the reasons to ask about specific performance data is to validate the general performance impact of using lambdas. In the case of WeekFields.of(), the lambda is passed on every call to `computeIfAbsent` even if the key is present and the lambda won't be used. `WeekFields` is way-way down the long tail of frequency of use and I expect that 99% of calls are for the same one or two combinations. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From djelinski at openjdk.org Wed Jul 6 08:57:23 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Jul 2022 08:57:23 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) test failure is unrelated, caused by [JDK-8289619](https://bugs.openjdk.org/browse/JDK-8289619) ------------- PR: https://git.openjdk.org/jdk/pull/9383 From dfuchs at openjdk.org Wed Jul 6 09:39:28 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 6 Jul 2022 09:39:28 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Changes to libnet look good. Please wait until you have obtained approvals from maintainers of the other areas to integrate, ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From itakiguchi at openjdk.org Wed Jul 6 16:23:22 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Wed, 6 Jul 2022 16:23:22 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets Message-ID: OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets. |Charset|Mix|SBCS|DBCS| | -- | -- | -- | -- | | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 | | Korean | Cp933 | Cp833 | Cp834 | But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets. I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency |Charset|Mix|SBCS|DBCS| | ------------- | ------------- | ------------- | ------------- | | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 | | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** | | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | *1: Cp037 compatible ------------- Commit messages: - 8289834: Missing SBCS and DBCS Only EBCDIC charsets Changes: https://git.openjdk.org/jdk/pull/9399/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9399&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289834 Stats: 369 lines in 6 files changed: 367 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9399.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9399/head:pull/9399 PR: https://git.openjdk.org/jdk/pull/9399 From itakiguchi at openjdk.org Wed Jul 6 16:23:22 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Wed, 6 Jul 2022 16:23:22 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi wrote: > OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets. > |Charset|Mix|SBCS|DBCS| > | -- | -- | -- | -- | > | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 | > | Korean | Cp933 | Cp833 | Cp834 | > > But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets. > > I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency > |Charset|Mix|SBCS|DBCS| > | ------------- | ------------- | ------------- | ------------- | > | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 | > | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** | > | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | > > *1: Cp037 compatible Discussions are available on : [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834): Add SBCS and DBCS Only EBCDIC charsets ------------- PR: https://git.openjdk.org/jdk/pull/9399 From djelinski at openjdk.org Wed Jul 6 05:32:29 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Jul 2022 05:32:29 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge remote-tracking branch 'origin' into unused-variables - Remove unused variables (windows) - Remove unused variables (macos) - Remove unused variables (linux) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9383/files - new: https://git.openjdk.org/jdk/pull/9383/files/915680c0..b4cd5374 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=00-01 Stats: 491 lines in 22 files changed: 458 ins; 5 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From weijun at openjdk.org Wed Jul 6 16:44:53 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 6 Jul 2022 16:44:53 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Changes in security (`java.security.jgss`, `jdk.crypto.cryptoki`, `jdk.crypto.mscapi`) look fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From aturbanov at openjdk.org Wed Jul 6 06:43:31 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 6 Jul 2022 06:43:31 GMT Subject: RFR: 8289706: (cs) Avoid redundant TreeMap.containsKey call in AbstractCharsetProvider In-Reply-To: References: Message-ID: <4Vsl21SoXcc7UWNYDvWmwQOHkBlUwarlBtrruD1Z42s=.d014ccc6-91ae-404f-a757-8973fb8a1b71@github.com> On Sat, 30 Apr 2022 09:45:07 GMT, Andrey Turbanov wrote: > The method `sun.nio.cs.ext.AbstractCharsetProvider#put` is effectively equivalent of `Map.putIfAbsent` call. > > https://github.com/openjdk/jdk/blob/df063f7db18a40ea7325fe608b3206a6dff812c1/src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java#L81-L84 > > Instead of hand-written method we can use `putIfAbsent` directly. > I makes code cleaner and gives a bit of performance. Thank your reviewers! ------------- PR: https://git.openjdk.org/jdk/pull/8483 From naoto at openjdk.org Wed Jul 6 19:46:33 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 6 Jul 2022 19:46:33 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9383 From smarks at openjdk.org Thu Jul 7 00:34:45 2022 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 7 Jul 2022 00:34:45 GMT Subject: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17] In-Reply-To: References: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com> Message-ID: On Wed, 1 Jun 2022 16:45:35 GMT, liach wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> do it as naotoj said > > 'the new' fix should be applied to newHashMap etc. too. @liach > 'the new' fix should be applied to newHashMap etc. too. I've filed [JDK-8289872](https://bugs.openjdk.org/browse/JDK-8289872) for this. It's a small thing but best to fix it before we forget about it. ------------- PR: https://git.openjdk.org/jdk/pull/8302 From alanb at openjdk.org Thu Jul 7 09:50:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 7 Jul 2022 09:50:39 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: References: Message-ID: <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com> On Wed, 6 Jul 2022 16:18:08 GMT, Ichiroh Takiguchi wrote: > Discussions are available on : > [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834): Add SBCS and DBCS Only EBCDIC charsets Yes, I think this need discussion on whether the JDK really needs to keep including and adding more EBCDIC charsets. I understand they can be useful for someone using JDBC to connect to a database on z/OS but this scenario would work equally well if the EBCDIC charsets were deployed on the class path or module path. Do you know if the icu4j project is still alive? I've often wondered why there wasn't more use of the provider mechanism. ------------- PR: https://git.openjdk.org/jdk/pull/9399 From naoto at openjdk.org Thu Jul 7 16:49:45 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 7 Jul 2022 16:49:45 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: References: Message-ID: <9GfdBeeI_GmXrZrgMxQBnPvPNK09f2E7XhgtrqT6b4I=.6eefa839-68be-4941-8d84-e7c4d81218b0@github.com> On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi wrote: > OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets. > |Charset|Mix|SBCS|DBCS| > | -- | -- | -- | -- | > | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 | > | Korean | Cp933 | Cp833 | Cp834 | > > But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets. > > I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency > |Charset|Mix|SBCS|DBCS| > | ------------- | ------------- | ------------- | ------------- | > | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 | > | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** | > | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | > > *1: Cp037 compatible I second Alan's comment here. I am not sure we could justify those legacy less common EBCDIC charsets making into the `jdk.charsets` module. Instead, utilizing the charset provider mechanism will better fit here to me. ------------- PR: https://git.openjdk.org/jdk/pull/9399 From cjplummer at openjdk.org Thu Jul 7 19:16:48 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 7 Jul 2022 19:16:48 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Are you going to update copyrights? I reviewed src/jdk.hotspot.agent, src/jdk.jdi/, src/jdk.jdwp.agent, and src/jdk.management. Looks good other than copyrights and the suggestion I made for additional cleanup in symtab.c. src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308: > 306: ELF_SHDR* shbuf = NULL; > 307: ELF_SHDR* cursct = NULL; > 308: ELF_PHDR* phbuf = NULL; phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too. ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Fri Jul 8 07:08:50 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:08:50 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> References: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> Message-ID: <5lYmVui3caVoMyThlWMlQP1etBfuLQan6v6OUIBYh_o=.e1d33b03-8791-4462-a9e7-b13287df2aa8@github.com> On Thu, 7 Jul 2022 19:06:52 GMT, Chris Plummer wrote: >> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin' into unused-variables >> - Remove unused variables (windows) >> - Remove unused variables (macos) >> - Remove unused variables (linux) > > src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308: > >> 306: ELF_SHDR* shbuf = NULL; >> 307: ELF_SHDR* cursct = NULL; >> 308: ELF_PHDR* phbuf = NULL; > > phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too. Good catch! Also removed similar code from macOS version. ------------- PR: https://git.openjdk.org/jdk/pull/9383 From alanb at openjdk.org Fri Jul 8 08:03:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 08:03:39 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Marked as reviewed by alanb (Reviewer). src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c line 686: > 684: LPCWSTR lpFileName = jlong_to_ptr(pathAddress); > 685: PSECURITY_DESCRIPTOR pSecurityDescriptor = jlong_to_ptr(descAddress); > 686: DWORD lengthNeeded = 0; lengthNeeded, it seems not :-) ------------- PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Fri Jul 8 07:12:44 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:12:44 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: <2_Xy-WrhqelW5xoQnKgSrnb1WSEENT6zlJ4ZRbnJDvo=.0e7b8752-9def-459a-ac6a-1172dbd3d5f7@github.com> On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Copyrights updated. ------------- PR: https://git.openjdk.org/jdk/pull/9383 From cjplummer at openjdk.org Fri Jul 8 07:20:46 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 8 Jul 2022 07:20:46 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9383 From duke at openjdk.org Fri Jul 8 13:55:47 2022 From: duke at openjdk.org (XenoAmess) Date: Fri, 8 Jul 2022 13:55:47 GMT Subject: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17] In-Reply-To: References: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com> Message-ID: On Wed, 1 Jun 2022 16:45:35 GMT, liach wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> do it as naotoj said > > 'the new' fix should be applied to newHashMap etc. too. > @liach > > > 'the new' fix should be applied to newHashMap etc. too. > > I've filed [JDK-8289872](https://bugs.openjdk.org/browse/JDK-8289872) for this. It's a small thing but best to fix it before we forget about it. Sorry for I already forgotten it. ------------- PR: https://git.openjdk.org/jdk/pull/8302 From djelinski at openjdk.org Fri Jul 8 07:08:46 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:08:46 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: - Update copyright - Remove more unused variables ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9383/files - new: https://git.openjdk.org/jdk/pull/9383/files/b4cd5374..da30ef90 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=01-02 Stats: 30 lines in 26 files changed: 0 ins; 4 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From cjplummer at openjdk.org Fri Jul 8 07:20:46 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 8 Jul 2022 07:20:46 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9383 From attila at openjdk.org Sun Jul 10 13:33:51 2022 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 10 Jul 2022 13:33:51 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v3] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Mon, 4 Jul 2022 07:06:30 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time Marked as reviewed by attila (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9208 From michaelm at openjdk.org Mon Jul 11 07:00:45 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 11 Jul 2022 07:00:45 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables libnet changes look fine to me ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From chegar at openjdk.org Mon Jul 11 08:13:45 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 11 Jul 2022 08:13:45 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: <0LufT1j0Gvkv3sFYqCQUR7aBmIU9lHIdOWBHVJyDc-M=.ee7f2980-e54f-4507-9ce3-73378faad4b8@github.com> On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Tue Jul 12 11:34:43 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Jul 2022 11:34:43 GMT Subject: Integrated: 8289768: Clean up unused code In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 20:19:10 GMT, Daniel Jeli?ski wrote: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. This pull request has now been integrated. Changeset: 04c47da1 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/04c47da118b2870d1c7525348a2ffdf9cd1cc0a4 Stats: 98 lines in 46 files changed: 0 ins; 69 del; 29 mod 8289768: Clean up unused code Reviewed-by: dfuchs, lancea, weijun, naoto, cjplummer, alanb, michaelm, chegar ------------- PR: https://git.openjdk.org/jdk/pull/9383 From ysatowse at openjdk.org Thu Jul 14 04:28:06 2022 From: ysatowse at openjdk.org (Yoshiki Sato) Date: Thu, 14 Jul 2022 04:28:06 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK Message-ID: Please review this PR. The PR open sources the closed timezone tests. ------------- Commit messages: - Minor change added to Makefile - 8028265: Move closed timezone tests to open repository Changes: https://git.openjdk.org/jdk/pull/9476/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9476&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8028265 Stats: 1221 lines in 9 files changed: 1221 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9476.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9476/head:pull/9476 PR: https://git.openjdk.org/jdk/pull/9476 From ysatowse at openjdk.org Thu Jul 14 04:28:06 2022 From: ysatowse at openjdk.org (Yoshiki Sato) Date: Thu, 14 Jul 2022 04:28:06 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. Can I ask you to help reviewing this PR? @coffeys @naotoj ------------- PR: https://git.openjdk.org/jdk/pull/9476 From coffeys at openjdk.org Thu Jul 14 04:28:08 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 14 Jul 2022 04:28:08 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. 1 minor comment. Looks good to me. test/jdk/java/util/TimeZone/tools/share/Makefile line 33: > 31: # > 32: > 33: TZDATA = ../../../../../../../../open/src/java.base/share/data/tzdata suggest you replace this with `../../../../../../../src/java.base/share/data/tzdata/` ------------- PR: https://git.openjdk.org/jdk/pull/9476 From naoto at openjdk.org Thu Jul 14 04:28:09 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 14 Jul 2022 04:28:09 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. Please modify the PR title to match the JBS. ------------- PR: https://git.openjdk.org/jdk/pull/9476 From coffeys at openjdk.org Thu Jul 14 08:19:47 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 14 Jul 2022 08:19:47 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. Marked as reviewed by coffeys (Reviewer). test/jdk/java/util/TimeZone/tools/share/makeZoneData.pl line 32: > 30: # static TimeZoneData. > 31: # For J2SE since JDK1.4, this script is used to generate testdata(reference) > 32: # for ZoneData.sh which is one of TimeZone Regression test. suggest that you remove these lines - redundant information. ------------- PR: https://git.openjdk.org/jdk/pull/9476 From naoto at openjdk.org Thu Jul 14 19:46:04 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 14 Jul 2022 19:46:04 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9476 From ysatowse at openjdk.org Fri Jul 15 07:18:52 2022 From: ysatowse at openjdk.org (Yoshiki Sato) Date: Fri, 15 Jul 2022 07:18:52 GMT Subject: Integrated: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. This pull request has now been integrated. Changeset: 92deab54 Author: Yoshiki Sato Committer: Sean Coffey URL: https://git.openjdk.org/jdk/commit/92deab546549ca549408a983fe361d9536d2cd37 Stats: 1221 lines in 9 files changed: 1221 ins; 0 del; 0 mod 8028265: Add legacy tz tests to OpenJDK Reviewed-by: coffeys, naoto ------------- PR: https://git.openjdk.org/jdk/pull/9476 From duke at openjdk.org Fri Jul 15 12:10:32 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:10:32 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable Message-ID: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Simplify code with `String.join()` ------------- Commit messages: - 8290300: Fix copy-right year - 8290300: Use standard String-joining tools where applicable Changes: https://git.openjdk.org/jdk/pull/9513/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290300 Stats: 90 lines in 8 files changed: 1 ins; 68 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From jlaskey at openjdk.org Fri Jul 15 12:28:48 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 15 Jul 2022 12:28:48 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` LGTM, however are there tests that ensure the changes are benign? ------------- PR: https://git.openjdk.org/jdk/pull/9513 From alanb at openjdk.org Fri Jul 15 12:33:48 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Jul 2022 12:33:48 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` joptsimple is a 3rd party code so we probably don't want to change that. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: - 8290300: Revert jops - 8290300: Revert jops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/f3020263..80384470 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=00-01 Stats: 73 lines in 4 files changed: 58 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` Reverted jops ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:25:07 GMT, Jim Laskey wrote: >> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8290300: Revert jops >> - 8290300: Revert jops > > LGTM, however are there tests that ensure the changes are benign? @JimLaskey I'll double check and add tests if necessary ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 16:16:37 2022 From: duke at openjdk.org (Ryan Ernst) Date: Fri, 15 Jul 2022 16:16:37 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base Message-ID: This commit guards uses of Files methods returning path streams in java.base to use try-with-resources. ------------- Commit messages: - 8290316: Ensure that all directory streams are closed in java.base Changes: https://git.openjdk.org/jdk/pull/9518/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9518&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290316 Stats: 52 lines in 5 files changed: 12 ins; 7 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/9518.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9518/head:pull/9518 PR: https://git.openjdk.org/jdk/pull/9518 From naoto at openjdk.org Fri Jul 15 16:31:46 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 15 Jul 2022 16:31:46 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <4lc5aVxpfSL9ukqHt2IDLR_LQDkQx-3htusBXQDsx1I=.9c453024-986b-4828-9775-f5a1561d0097@github.com> On Fri, 15 Jul 2022 12:40:50 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: > > - 8290300: Revert jops > - 8290300: Revert jops Changes to `Locale` look good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/9513 From alanb at openjdk.org Fri Jul 15 16:38:12 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Jul 2022 16:38:12 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 16:06:21 GMT, Ryan Ernst wrote: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. Changing these usages to close the stream is good but needs to keep the formatting/style consistent with the existing code. Also can you make sure the copyright date is updated on the files that need it. src/java.base/share/classes/java/time/chrono/HijrahChronology.java line 1040: > 1038: if (Files.isDirectory(CONF_PATH)) { > 1039: try (Stream stream = Files.list(CONF_PATH)) { > 1040: stream.map(p -> p.getFileName().toString()) I can't tell if there is a tab here but it looks like you've changed this to indent by 8 instead of 4 spaces. src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 141: > 139: .map(path -> toPackageName(top, path)) > 140: .filter(Checks::isPackageName) > 141: .forEach(packages::add); The formatting seems to a bit messed up here too, I don't know if you means to do that. In the try-block the indentation of stream.filter should be 4 spaces, not 8. Also can you restore the alignment of the expression provided to filter then it will be easier to read. src/java.base/share/classes/jdk/internal/module/ModulePath.java line 669: > 667: try (Stream stream = > 668: Files.find(dir, Integer.MAX_VALUE, (path, attrs) -> attrs.isRegularFile() && !isHidden(path))) { > 669: return stream.map(dir::relativize) This is inconsistent with existing code. If you change to something like the following then it would make future side-by-side diffs easier to read: try (Stream s = Files.find(dir, Integer.MAX_VALUE, (path, attrs) -> attrs.isRegularFile() && !isHidden(path))) { return s.map(...); } catch (IOException x) { throw new UncheckedIOException(x); } ------------- Changes requested by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/9518 From alanb at openjdk.org Fri Jul 15 16:43:06 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Jul 2022 16:43:06 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base In-Reply-To: References: Message-ID: <-XwW6yYEuhCSKzYzMkz7EwBvlZLWtgLZBg5lClwS1MM=.e4c21bb0-c341-46dc-90fe-9be6e92ad82d@github.com> On Fri, 15 Jul 2022 16:06:21 GMT, Ryan Ernst wrote: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. src/java.base/share/classes/jdk/internal/module/ModuleHashes.java line 119: > 117: } > 118: try { > 119: byte[] buf = new byte[32*1024]; Can you move the declaration of bug to before the try? That would reduce the nesting. ------------- PR: https://git.openjdk.org/jdk/pull/9518 From duke at openjdk.org Fri Jul 15 19:33:56 2022 From: duke at openjdk.org (Ryan Ernst) Date: Fri, 15 Jul 2022 19:33:56 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v2] In-Reply-To: References: Message-ID: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: address formatting feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9518/files - new: https://git.openjdk.org/jdk/pull/9518/files/bba7406f..c0a09f91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9518&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9518&range=00-01 Stats: 25 lines in 4 files changed: 3 ins; 4 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9518.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9518/head:pull/9518 PR: https://git.openjdk.org/jdk/pull/9518 From duke at openjdk.org Fri Jul 15 19:33:57 2022 From: duke at openjdk.org (Ryan Ernst) Date: Fri, 15 Jul 2022 19:33:57 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 16:06:21 GMT, Ryan Ernst wrote: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. Thanks Alan. The 8 space indents were unintentional. I think I've addressed all your comments in [c0a09f9](https://github.com/openjdk/jdk/pull/9518/commits/c0a09f91be22acce0555e5a8d06023975185d307). ------------- PR: https://git.openjdk.org/jdk/pull/9518 From duke at openjdk.org Sat Jul 16 03:39:11 2022 From: duke at openjdk.org (Bernd) Date: Sat, 16 Jul 2022 03:39:11 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v2] In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 19:33:56 GMT, Ryan Ernst wrote: >> This commit guards uses of Files methods returning path streams in >> java.base to use try-with-resources. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > address formatting feedback src/java.base/share/classes/java/time/chrono/HijrahChronology.java line 1041: > 1039: try (Stream stream = Files.list(CONF_PATH)) { > 1040: stream.map(p -> p.getFileName().toString()) > 1041: .filter(fn -> fn.matches("hijrah-config-[^\\.]+\\.properties")) BTW Should this use RESOURCE_PREFIX/SUFFIX and is the \\ inside [character class] suppose to quote the .? ------------- PR: https://git.openjdk.org/jdk/pull/9518 From chegar at openjdk.org Sat Jul 16 08:43:46 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Sat, 16 Jul 2022 08:43:46 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v2] In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 19:33:56 GMT, Ryan Ernst wrote: >> This commit guards uses of Files methods returning path streams in >> java.base to use try-with-resources. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > address formatting feedback Changes requested by chegar (Reviewer). src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 262: > 260: p = module.relativize(p); > 261: String pkgName = slashesToDots(p.toString()); > 262: // skip META-INFO and empty strings Trivially, while here can we fix this typo, META-INFO <- drop the `O` src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 271: > 269: moduleNames.add(moduleName); > 270: } > 271: }); There is a missing closing curly brace here (which should come on the next line), but otherwise looks fine. src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 138: > 136: stream.filter(path -> (!isAutomatic > 137: || path.toString().endsWith(".class")) > 138: && !isHidden(path)) Trivially, can the indentation of the two boolean operators be pushed in so that they align underneath the lambda parameter. ------------- PR: https://git.openjdk.org/jdk/pull/9518 From chegar at openjdk.org Sat Jul 16 08:43:47 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Sat, 16 Jul 2022 08:43:47 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v2] In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 03:35:06 GMT, Bernd wrote: >> Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> address formatting feedback > > src/java.base/share/classes/java/time/chrono/HijrahChronology.java line 1041: > >> 1039: try (Stream stream = Files.list(CONF_PATH)) { >> 1040: stream.map(p -> p.getFileName().toString()) >> 1041: .filter(fn -> fn.matches("hijrah-config-[^\\.]+\\.properties")) > > BTW Should this use RESOURCE_PREFIX/SUFFIX and is the \\ inside [character class] suppose to quote the .? @ecki this seems orthogonal to this particular issue. Maybe it could be considered separately, if needed. ------------- PR: https://git.openjdk.org/jdk/pull/9518 From prr at openjdk.org Mon Jul 18 00:33:55 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 18 Jul 2022 00:33:55 GMT Subject: RFR: 8285306: Fix typos in java.desktop [v6] In-Reply-To: <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com> References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com> Message-ID: On Fri, 13 May 2022 16:53:00 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos. >> >> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay. >> >> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). >> >> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. > > Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision: > > - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5 We need to revert the native code changes to "libfreetype". These are 3rd party imported files. After that we should get this pushed and move on and I agree that no matter the similarity this PR is TOO BIG. Which is I think mostly why it has taken this long and still not done. ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/8328 From duke at openjdk.org Mon Jul 18 11:17:37 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:17:37 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v3] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <6NKq2IAULEe2WYW2aIEOvu9-8_p4aKtrW1ZFRJo16mc=.17712761-2483-49b4-acf4-2faa394a1a99@github.com> > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Remove unused piece of code in formatList() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/80384470..4f2bbfd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 11:17:37 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:17:37 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v3] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:25:07 GMT, Jim Laskey wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290300: Remove unused piece of code in formatList() > > LGTM, however are there tests that ensure the changes are benign? @JimLaskey changes in `WindowsPath` are covered by `PathOps`, apart from this there are 10 tests calling this method. With `ProcessBuilder` and `Locale` it looks like the code I've changed is never executed at all for `ProcessStartEvent.isEnabled()` always return false. For `Locale` all the call sites of `formatList()` never pass null, so the code in `if` block is never executed. I think we can delete this unused parts of the code in `Locale`, but I'm not sure about `ProcessBuilder`. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 11:31:59 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:31:59 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Remove unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/4f2bbfd3..5b18c39c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 14:02:47 2022 From: duke at openjdk.org (Ryan Ernst) Date: Mon, 18 Jul 2022 14:02:47 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v3] In-Reply-To: References: Message-ID: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: fix compile and address more feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9518/files - new: https://git.openjdk.org/jdk/pull/9518/files/c0a09f91..b5076b1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9518&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9518&range=01-02 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9518.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9518/head:pull/9518 PR: https://git.openjdk.org/jdk/pull/9518 From chegar at openjdk.org Mon Jul 18 15:24:54 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 18 Jul 2022 15:24:54 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v3] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 14:02:47 GMT, Ryan Ernst wrote: >> This commit guards uses of Files methods returning path streams in >> java.base to use try-with-resources. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > fix compile and address more feedback LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/9518 From naoto at openjdk.org Mon Jul 18 16:49:45 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 18 Jul 2022 16:49:45 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Mon, 18 Jul 2022 11:08:24 GMT, ?????? ??????? wrote: > For `Locale` all the call sites of `formatList()` never pass null, so the code in `if` block is never executed. I think we can delete this unused parts of the code in `Locale`, Are you sure about this? `pattern` is derived from `LocaleResources.getLocaleName()` which could return `null`. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 18:40:51 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 18:40:51 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Revert erroneous changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/5b18c39c..af555897 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=03-04 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 18:40:51 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 18:40:51 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Mon, 18 Jul 2022 11:31:59 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Remove unused import Right, my bad. I've confused arguments. The changes reverted. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From naoto at openjdk.org Mon Jul 18 18:56:50 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 18 Jul 2022 18:56:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> Message-ID: <9nxXC6TKJOwD19iPW3lSojz6aWMT91DCTH3rrqx4C-8=.d43bb635-f3b1-4ebf-8baa-7b85078b7694@github.com> On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Revert erroneous changes Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9513 From rriggs at openjdk.org Mon Jul 18 19:10:11 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 18 Jul 2022 19:10:11 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> Message-ID: <4MM9EyQBrfbebIry8tPi_LRPHaRGPbmVYp7xwf0hewQ=.6ae982ac-d33f-49f0-927c-f574c148ec35@github.com> On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Revert erroneous changes Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9513 From aturbanov at openjdk.org Wed Jul 20 11:19:07 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 20 Jul 2022 11:19:07 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v4] In-Reply-To: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: > Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time revert 'computeIfAbsent' when it requires custom key class. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9208/files - new: https://git.openjdk.org/jdk/pull/9208/files/70223b4b..94f57445 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9208&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9208&range=02-03 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9208.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9208/head:pull/9208 PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Wed Jul 20 11:21:21 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 20 Jul 2022 11:21:21 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> <6vhuyCUEh-vPPge9hMbzMfAlKQ7bqKSxAMgScEkCAtE=.9202220b-4c2f-4d28-96a5-c6328fd54f53@github.com> Message-ID: On Wed, 6 Jul 2022 14:11:39 GMT, Roger Riggs wrote: >> @RogerRiggs in my view, it's not about performance per se??I'll sometimes help along these kinds of small fix PRs (that are more likely than not driven by IntelliJ code refactoring suggestions) if I think they lead to more idiomatic code in the JDK with no drawbacks. I think there's value in periodically revisiting existing code and improve it to use new language and library construct that have become available since ? people study JDK source code, and I think it's important they see as good examples in there as possible. I do like seeing an old example of hand-rolled compute-if-absent being replaced by an actual `computeIfAbsent` call. Similarly, I think using records as composite keys is in general a better practice over simulating a composite key by creating a string representation of it. >> >> Yeah, it'll load additional code at runtime for that record's class, and yes, I'm aware records' `hashCode`/`equals`/`toString` are implemented by delegating to factory methods that heavily use method handle combinators. If records are meant as lightweight value-semantics composites, it should be okay to use them like this and if there are performance concerns with their use, then those concerns should be addressed by improving their performance. OTOH, MH combinators installed into constant call sites are well optimized by HotSpot these days??anyhow, a discussion for another day. >> >> In this specific instance, the value domain of the keys is limited, but the number of method calls to `WeekFields.of` isn't. It could be benchmarked but if there's concerns, it's also okay to de-scope the record-as-key from this PR. I don't have strong feelings either way. > > The comment was about WeekFields.of(), I misplaced the comment. > > @szegedi All good points about modernizing code... > One of the reasons to ask about specific performance data is to validate the general performance impact of using lambdas. In the case of WeekFields.of(), the lambda is passed on every call to `computeIfAbsent` even if the key is present and the lambda won't be used. `WeekFields` is way-way down the long tail of frequency of use and I expect that 99% of calls are for the same one or two combinations. I agree with @RogerRiggs that performance of JDK is very important. It was one of main motivation for removing `.get` call. I'm not an expert in microbenchmarking, and it would require significant time/resources for me to investigate which is better. So I decided to revert back to original proposal (without lambda and `computeIfAbsent`) in `WeekFields`. If you think that it's better to improve code, I think we can always fill a separate issue for it. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From attila at openjdk.org Wed Jul 20 18:08:00 2022 From: attila at openjdk.org (Attila Szegedi) Date: Wed, 20 Jul 2022 18:08:00 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v4] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Wed, 20 Jul 2022 11:19:07 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time > > revert 'computeIfAbsent' when it requires custom key class. Marked as reviewed by attila (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9208 From attila at openjdk.org Wed Jul 20 18:08:02 2022 From: attila at openjdk.org (Attila Szegedi) Date: Wed, 20 Jul 2022 18:08:02 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> <6vhuyCUEh-vPPge9hMbzMfAlKQ7bqKSxAMgScEkCAtE=.9202220b-4c2f-4d28-96a5-c6328fd54f53@github.com> Message-ID: On Wed, 20 Jul 2022 11:19:11 GMT, Andrey Turbanov wrote: >> The comment was about WeekFields.of(), I misplaced the comment. >> >> @szegedi All good points about modernizing code... >> One of the reasons to ask about specific performance data is to validate the general performance impact of using lambdas. In the case of WeekFields.of(), the lambda is passed on every call to `computeIfAbsent` even if the key is present and the lambda won't be used. `WeekFields` is way-way down the long tail of frequency of use and I expect that 99% of calls are for the same one or two combinations. > > I agree with @RogerRiggs that performance of JDK is very important. It was one of main motivation for removing `.get` call. > I'm not an expert in microbenchmarking, and it would require significant time/resources for me to investigate which is better. > So I decided to revert back to original proposal (without lambda and `computeIfAbsent`) in `WeekFields`. If you think that it's better to improve code, I think we can always fill a separate issue for it. Fair. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From rriggs at openjdk.org Wed Jul 20 18:16:00 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 20 Jul 2022 18:16:00 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v4] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Wed, 20 Jul 2022 11:19:07 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time > > revert 'computeIfAbsent' when it requires custom key class. Looks good, thanks ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9208 From duke at openjdk.org Thu Jul 21 06:23:06 2022 From: duke at openjdk.org (Ryan Ernst) Date: Thu, 21 Jul 2022 06:23:06 GMT Subject: Integrated: 8290316: Ensure that all directory streams are closed in java.base In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 16:06:21 GMT, Ryan Ernst wrote: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. This pull request has now been integrated. Changeset: 53fc495e Author: Ryan Ernst Committer: Chris Hegarty URL: https://git.openjdk.org/jdk/commit/53fc495e3aca7d89af697639d727051fb9adf9c7 Stats: 38 lines in 5 files changed: 8 ins; 3 del; 27 mod 8290316: Ensure that all directory streams are closed in java.base Reviewed-by: chegar ------------- PR: https://git.openjdk.org/jdk/pull/9518 From aturbanov at openjdk.org Thu Jul 21 10:24:15 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 21 Jul 2022 10:24:15 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v4] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: <3SfGNgdGfFlMG6G3Vfi8ZhXWwGCag5yA3_44kzuEIWo=.3a8de0e2-2ad6-43ae-9c14-bbe8b4e06110@github.com> On Wed, 20 Jul 2022 11:19:07 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time > > revert 'computeIfAbsent' when it requires custom key class. Thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Thu Jul 21 10:27:04 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 21 Jul 2022 10:27:04 GMT Subject: Integrated: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time In-Reply-To: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: <0OGe40FCcdVT8cbaEo9RWPhz0XvZ9qYx2gm9v18VeX4=.ec405884-3d16-4e16-a386-ab3486d5bd72@github.com> On Sat, 18 Jun 2022 10:43:08 GMT, Andrey Turbanov wrote: > Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. This pull request has now been integrated. Changeset: 52cc6cd0 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/52cc6cd063c167229f8883ba5a81be306c38a73c Stats: 30 lines in 4 files changed: 2 ins; 16 del; 12 mod 8288723: Avoid redundant ConcurrentHashMap.get call in java.time Reviewed-by: attila, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/9208 From naoto at openjdk.org Fri Jul 22 22:01:39 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 22 Jul 2022 22:01:39 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content Message-ID: This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. ------------- Commit messages: - IllformedLocaleEx -> LocaleSyntaxEx - SystemProperty tests - Revived returning Optional - Some clean-ups, including making Extension a sealed class. - Bring the specialized methods back - Using Optional - FieldSeparators()/FieldSubtag() -> Fields() - 8289227: Support for BCP 47 Extension T - T-ext Changes: https://git.openjdk.org/jdk/pull/9620/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289227 Stats: 776 lines in 23 files changed: 600 ins; 135 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From achung at openjdk.org Sat Jul 23 03:11:02 2022 From: achung at openjdk.org (Alisen Chung) Date: Sat, 23 Jul 2022 03:11:02 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 Message-ID: open l10n msg drop All tests passed. ------------- Commit messages: - open l10n drop Changes: https://git.openjdk.org/jdk19/pull/154/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290889 Stats: 3930 lines in 44 files changed: 3336 ins; 540 del; 54 mod Patch: https://git.openjdk.org/jdk19/pull/154.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154 PR: https://git.openjdk.org/jdk19/pull/154 From naoto at openjdk.org Mon Jul 25 16:10:02 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 25 Jul 2022 16:10:02 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v2] In-Reply-To: References: Message-ID: > This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed unnecessary `contains()` check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9620/files - new: https://git.openjdk.org/jdk/pull/9620/files/1f1526bc..a869efaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=00-01 Stats: 5 lines in 3 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From naoto at openjdk.org Mon Jul 25 17:05:38 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 25 Jul 2022 17:05:38 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung wrote: > open l10n msg drop > All tests passed. Changes requested by naoto (Reviewer). src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP These currency symbols (`XXX=XXX`) are all in the base `CurrencyNames.properties`, so not needed in each localized resources (They are in the base in order to avoid throwing exceptions). Also, the localized files should not reside in `java.base`, but to be merged with the ones in `jdk.localedata` module These comments hold for all localized resources (de, ja, zh-CN). For furure reference, it may be good to add some comment in the base `CurrencyNames.properties` about this. src/java.base/share/data/currency/CurrencyData_de.properties line 1: > 1: # `CurrencyData.properties` is not a localizable resource bundle, but a properties file containing currency data. No need to add these localized resources. ------------- PR: https://git.openjdk.org/jdk19/pull/154 From asemenyuk at openjdk.org Mon Jul 25 18:52:15 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 25 Jul 2022 18:52:15 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com> On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung wrote: > open l10n msg drop > All tests passed. Why `MSG_Help_mac_launcher` in [src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties](https://github.com/openjdk/jdk19/pull/154/files#diff-2e1b121e201e1040827d5b68ebdd852615e611904db783806a753dc6980e97fa) is left not localized? Is it intended to be localized in the next drop? ------------- PR: https://git.openjdk.org/jdk19/pull/154 From joehw at openjdk.org Tue Jul 26 01:36:47 2022 From: joehw at openjdk.org (Joe Wang) Date: Tue, 26 Jul 2022 01:36:47 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 16:10:02 GMT, Naoto Sato wrote: >> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary `contains()` check Looks good to me. Some minor comments below. src/java.base/share/classes/java/util/Locale.java line 236: > 234: * particular Unicode locale attributes or key/type pairs. > 235: * > 236: *

Transformed Content extension

Both the full name "Transformed Content extension" and the abbreviated forms "T Extension" are used in this document. I see Unicode and the RFC referred to it as "T Extension", " 't' Extension", and "Extension T". If we describe the extension as "T Extension", maybe we can make it clear in the title, e.g.: Transformed Content (T) Extension could thus in the doc thereafter use "T Extension". The existing methods look like used full extension name, but for T Extension, the short form, e.g. getTExtensionFields also matches its javadoc ("Returns the map of fields in the T extension"). Your call. src/java.base/share/classes/java/util/Locale.java line 265: > 263: * field separator (one alpha + one digit), followed by one or more subtags of the length 3 to 8, > 264: * each delimited by a hyphen. > 265: *

The transformed content information {@code source} language tag and {@code fields} are returned "transformed content information" seems not needed as "The {@code source} language tag and {@code fields}" are known from the previous paragraph. src/java.base/share/classes/sun/util/locale/TransformedContentExtension.java line 40: > 38: public final class TransformedContentExtension extends Extension { > 39: > 40: public static final char SINGLETON = 't'; "singleton" as in "The singleton identifier" in the doc, seems to mean the key consists of a single character. But it can be confused with the Singleton pattern. T_EXTENSION_KEY (as methods such as isTransformedContentxxx expect a key) or Locale.TRANSFORMED_CONTENT_EXTENSION might be better. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From naoto at openjdk.org Tue Jul 26 17:17:46 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 26 Jul 2022 17:17:46 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v3] In-Reply-To: References: Message-ID: > This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. Naoto Sato 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 12 additional commits since the last revision: - Modified javadoc of the transformed conent - Merge branch 'master' into JDK-8289227-T-ext - Removed unnecessary `contains()` check - IllformedLocaleEx -> LocaleSyntaxEx - SystemProperty tests - Revived returning Optional - Some clean-ups, including making Extension a sealed class. - Bring the specialized methods back Some documentation fixes - Using Optional - FieldSeparators()/FieldSubtag() -> Fields() - ... and 2 more: https://git.openjdk.org/jdk/compare/69ea6e10...780f712e ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9620/files - new: https://git.openjdk.org/jdk/pull/9620/files/a869efaa..780f712e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=01-02 Stats: 6329 lines in 181 files changed: 3452 ins; 2172 del; 705 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From naoto at openjdk.org Tue Jul 26 17:27:07 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 26 Jul 2022 17:27:07 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v2] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 01:07:29 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unnecessary `contains()` check > > src/java.base/share/classes/java/util/Locale.java line 236: > >> 234: * particular Unicode locale attributes or key/type pairs. >> 235: * >> 236: *

Transformed Content extension

> > Both the full name "Transformed Content extension" and the abbreviated forms "T Extension" are used in this document. I see Unicode and the RFC referred to it as "T Extension", " 't' Extension", and "Extension T". If we describe the extension as "T Extension", maybe we can make it clear in the title, e.g.: > Transformed Content (T) Extension > > could thus in the doc thereafter use "T Extension". The existing methods look like used full extension name, but for T Extension, the short form, e.g. getTExtensionFields also matches its javadoc ("Returns the map of fields in the T extension"). Your call. Thanks for the suggestion, Joe. I made changes to the `Locale` class documentation, mainly to spell out `transformed content`, instead of using `T`. I believe that would be more descriptive. Since the RFC title uses `T`, I added it in the section title. > src/java.base/share/classes/java/util/Locale.java line 265: > >> 263: * field separator (one alpha + one digit), followed by one or more subtags of the length 3 to 8, >> 264: * each delimited by a hyphen. >> 265: *

The transformed content information {@code source} language tag and {@code fields} are returned > > "transformed content information" seems not needed as "The {@code source} language tag and {@code fields}" are known from the previous paragraph. Modified to make it more sense. > src/java.base/share/classes/sun/util/locale/TransformedContentExtension.java line 40: > >> 38: public final class TransformedContentExtension extends Extension { >> 39: >> 40: public static final char SINGLETON = 't'; > > "singleton" as in "The singleton identifier" in the doc, seems to mean the key consists of a single character. But it can be confused with the Singleton pattern. T_EXTENSION_KEY (as methods such as isTransformedContentxxx expect a key) or Locale.TRANSFORMED_CONTENT_EXTENSION might be better. This is analogous to the implementation of `UnicodeLocaleExtension`, and I believe this means the singleton as in the pattern. No need to use literal `t` everywhere. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From achung at openjdk.org Tue Jul 26 18:34:58 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 26 Jul 2022 18:34:58 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 In-Reply-To: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com> References: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com> Message-ID: On Mon, 25 Jul 2022 18:48:25 GMT, Alexey Semenyuk wrote: > Why `MSG_Help_mac_launcher` in [src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties](https://github.com/openjdk/jdk19/pull/154/files#diff-2e1b121e201e1040827d5b68ebdd852615e611904db783806a753dc6980e97fa) is left not localized? Is it intended to be localized in the next drop? Probably will be left for next drop ------------- PR: https://git.openjdk.org/jdk19/pull/154 From rriggs at openjdk.org Tue Jul 26 18:57:30 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 26 Jul 2022 18:57:30 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 17:17:46 GMT, Naoto Sato wrote: >> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. > > Naoto Sato 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 12 additional commits since the last revision: > > - Modified javadoc of the transformed conent > - Merge branch 'master' into JDK-8289227-T-ext > - Removed unnecessary `contains()` check > - IllformedLocaleEx -> LocaleSyntaxEx > - SystemProperty tests > - Revived returning Optional > - Some clean-ups, including making Extension a sealed class. > - Bring the specialized methods back > Some documentation fixes > - Using Optional > - FieldSeparators()/FieldSubtag() -> Fields() > - ... and 2 more: https://git.openjdk.org/jdk/compare/59bcd12a...780f712e The basic support for the "t" extension is covered by the existing methods for `Locale.getExtension()` and `Locale.Builder.setExtension`. At least initially, there will be very few developers and applications using transformed content. The transformed content extension syntax is well defined by BCP 47 and applications that need the source language or fields have a well defined format they can parse themselves from the value returned from `getExtension('t')`. I'm concerned about adding API and implementation complexity that may not be used and might accumulate in the JDK without ever being used. The parsing of the source locale and fields is a convenience but not essential to 't' support. I would suggest deferring the APIs for `getTransformedContentFields()` and `getTransformedContentSource()`. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From joehw at openjdk.org Tue Jul 26 19:06:08 2022 From: joehw at openjdk.org (Joe Wang) Date: Tue, 26 Jul 2022 19:06:08 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 17:17:46 GMT, Naoto Sato wrote: >> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. > > Naoto Sato 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 12 additional commits since the last revision: > > - Modified javadoc of the transformed conent > - Merge branch 'master' into JDK-8289227-T-ext > - Removed unnecessary `contains()` check > - IllformedLocaleEx -> LocaleSyntaxEx > - SystemProperty tests > - Revived returning Optional > - Some clean-ups, including making Extension a sealed class. > - Bring the specialized methods back > Some documentation fixes > - Using Optional > - FieldSeparators()/FieldSubtag() -> Fields() > - ... and 2 more: https://git.openjdk.org/jdk/compare/8de5da37...780f712e Looks good to me. src/java.base/share/classes/java/util/Locale.java line 265: > 263: * field separator (one alpha + one digit), followed by one or more subtags of the length 3 to 8, > 264: * each delimited by a hyphen. > 265: *

The transformed content information; namely {@code source} language tag and {@code fields} typo ";" (s/;/,) ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.org/jdk/pull/9620 From naoto at openjdk.org Tue Jul 26 20:20:07 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 26 Jul 2022 20:20:07 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 19:03:24 GMT, Joe Wang wrote: >> Naoto Sato 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 12 additional commits since the last revision: >> >> - Modified javadoc of the transformed conent >> - Merge branch 'master' into JDK-8289227-T-ext >> - Removed unnecessary `contains()` check >> - IllformedLocaleEx -> LocaleSyntaxEx >> - SystemProperty tests >> - Revived returning Optional >> - Some clean-ups, including making Extension a sealed class. >> - Bring the specialized methods back >> Some documentation fixes >> - Using Optional >> - FieldSeparators()/FieldSubtag() -> Fields() >> - ... and 2 more: https://git.openjdk.org/jdk/compare/b512a057...780f712e > > src/java.base/share/classes/java/util/Locale.java line 265: > >> 263: * field separator (one alpha + one digit), followed by one or more subtags of the length 3 to 8, >> 264: * each delimited by a hyphen. >> 265: *

The transformed content information; namely {@code source} language tag and {@code fields} > > typo ";" (s/;/,) Actually, I did mean a semicolon, but a comma may be better in this case. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From achung at openjdk.org Tue Jul 26 20:24:14 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 26 Jul 2022 20:24:14 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: > open l10n msg drop > All tests passed. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: merged currencyname property files into localedata ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/154/files - new: https://git.openjdk.org/jdk19/pull/154/files/334f4c76..7ab703ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=00-01 Stats: 1540 lines in 7 files changed: 3 ins; 1534 del; 3 mod Patch: https://git.openjdk.org/jdk19/pull/154.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154 PR: https://git.openjdk.org/jdk19/pull/154 From achung at openjdk.org Tue Jul 26 20:31:44 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 26 Jul 2022 20:31:44 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: Message-ID: > open l10n msg drop > All tests passed. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: removed localized files from base ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/154/files - new: https://git.openjdk.org/jdk19/pull/154/files/7ab703ed..6776bd0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=01-02 Stats: 1722 lines in 3 files changed: 0 ins; 1722 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/154.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154 PR: https://git.openjdk.org/jdk19/pull/154 From naoto at openjdk.org Tue Jul 26 20:42:37 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 26 Jul 2022 20:42:37 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v4] In-Reply-To: References: Message-ID: > This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed convenient APIs for now ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9620/files - new: https://git.openjdk.org/jdk/pull/9620/files/780f712e..e24e5dd8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=02-03 Stats: 63 lines in 2 files changed: 0 ins; 60 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From naoto at openjdk.org Tue Jul 26 20:56:05 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 26 Jul 2022 20:56:05 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 18:41:57 GMT, Roger Riggs wrote: > I would suggest deferring the APIs for `getTransformedContentFields()` and `getTransformedContentSource()`. OK, removed those two convenient APIs. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From naoto at openjdk.org Wed Jul 27 18:13:34 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 27 Jul 2022 18:13:34 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug Message-ID: Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. ------------- Commit messages: - Fix 0x25 c2b in IBM864 Changes: https://git.openjdk.org/jdk/pull/9661/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9661&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290488 Stats: 6 lines in 3 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9661.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9661/head:pull/9661 PR: https://git.openjdk.org/jdk/pull/9661 From iris at openjdk.org Wed Jul 27 19:19:13 2022 From: iris at openjdk.org (Iris Clark) Date: Wed, 27 Jul 2022 19:19:13 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote: > Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9661 From duke at openjdk.org Wed Jul 27 20:18:16 2022 From: duke at openjdk.org (Gaurav Chaudhari) Date: Wed, 27 Jul 2022 20:18:16 GMT Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable [v3] In-Reply-To: References: Message-ID: > This is a REDO of the Fix that was incompletely implemented earlier: > [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660) > > Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days. > > I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works: > _(where 7200 represents 7200 seconds -> +2 hour offset)_ > Sample output: > ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png) Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision: 8288377: Added GMT0 corner case and minor format fixes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9312/files - new: https://git.openjdk.org/jdk/pull/9312/files/7e462d95..8ca0a727 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9312&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9312&range=01-02 Stats: 22 lines in 1 file changed: 20 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9312.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9312/head:pull/9312 PR: https://git.openjdk.org/jdk/pull/9312 From duke at openjdk.org Wed Jul 27 20:18:17 2022 From: duke at openjdk.org (Gaurav Chaudhari) Date: Wed, 27 Jul 2022 20:18:17 GMT Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable [v2] In-Reply-To: <9HAc2av3J84YjjL6VgQLfSlMAUkicHuic2ONLc7x3ZA=.4b01d5f6-6a96-4996-bd83-be9ce5d19c41@github.com> References: <9HAc2av3J84YjjL6VgQLfSlMAUkicHuic2ONLc7x3ZA=.4b01d5f6-6a96-4996-bd83-be9ce5d19c41@github.com> Message-ID: On Thu, 30 Jun 2022 20:05:05 GMT, Naoto Sato wrote: >> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision: >> >> 8288377: Simplified TZ offset calc and consolidate MACOS impl. > > src/java.base/unix/native/libjava/TimeZone_md.c line 569: > >> 567: } >> 568: >> 569: strftime(offset, 6, "%z", &localtm); > > Return value has to be examined. If it is not `5`, then I'd expect falling back to "GMT". Added check to verify output is as expected before proceeding, with fallback > src/java.base/unix/native/libjava/TimeZone_md.c line 572: > >> 570: char gmt_offset[] = {offset[0], offset[1], offset[2], ':', offset[3], offset[4], '\0'}; >> 571: >> 572: sprintf(buf, (const char *)"GMT%s", gmt_offset); > > You could use the format string as "GMT%c%c%c:%c%c" so that the extra `gmt_offset` variable can be eliminated. Adjusted, forgot that the final string returned was able to be formatted itself as well. ------------- PR: https://git.openjdk.org/jdk/pull/9312 From naoto at openjdk.org Wed Jul 27 22:35:50 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 27 Jul 2022 22:35:50 GMT Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable [v3] In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 20:18:16 GMT, Gaurav Chaudhari wrote: >> This is a REDO of the Fix that was incompletely implemented earlier: >> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660) >> >> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days. >> >> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works: >> _(where 7200 represents 7200 seconds -> +2 hour offset)_ >> Sample output: >> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png) > > Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision: > > 8288377: Added GMT0 corner case and minor format fixes. Thanks. Looks good with one minor request. src/java.base/unix/native/libjava/TimeZone_md.c line 587: > 585: > 586: strftime(offset, 6, "%z", &localtm); > 587: if (strlen(offset) != 5) { What I meant was the return value from `strftime`, not the length from `strlen`, ie, `if (strftime(...) != 5)`. It should be more robust. ------------- Changes requested by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/9312 From itakiguchi at openjdk.org Thu Jul 28 01:01:08 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Thu, 28 Jul 2022 01:01:08 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote: > Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. Hello @naotoj . I'm not reviewer, but I'd like to test this change. Could you wait for a moment ? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9661 From naoto at openjdk.org Thu Jul 28 01:48:33 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 28 Jul 2022 01:48:33 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 00:58:59 GMT, Ichiroh Takiguchi wrote: >> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. > > Hello @naotoj . > I'm not reviewer, but I'd like to test this change. > Could you wait for a moment ? > Thanks. @takiguc Sure. Appreciate it. ------------- PR: https://git.openjdk.org/jdk/pull/9661 From itakiguchi at openjdk.org Thu Jul 28 10:32:48 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Thu, 28 Jul 2022 10:32:48 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: <0dcA7IfbHxn9XCjncuVEVSoA6jcygKHckFumifkPmuM=.adf1d4ff-dfc0-4f23-bfd2-94b03d773624@github.com> On Thu, 28 Jul 2022 01:46:26 GMT, Naoto Sato wrote: >> Hello @naotoj . >> I'm not reviewer, but I'd like to test this change. >> Could you wait for a moment ? >> Thanks. > > @takiguc Sure. Appreciate it. Many thanks @naotoj . I checked the latest IBM-864 mapping table. (I assume current OpenJDK's IBM864 may refer older mapping table) https://raw.githubusercontent.com/unicode-org/icu/main/icu4c/source/data/mappings/ibm-864_X110-1999.ucm .ucm file format is as follows: https://unicode-org.github.io/icu/userguide/conversion/data.html#ucm-file-format I checked roundtrip mapping | IBM864.map | ibm-864_X110-1999.ucm | | --- | --- | | 0x1a U+001a | 0x1a U+001c | | 0x1c U+001c | 0x1c U+007f | | **0x25 U+066a** | **0x25 U+0025** | | 0x7f U+007f | 0x7f U+001a | | 0x9f U+fffd | 0x9f U+200b | | 0xd7 U+fec1 | 0xd7 U+fec3 | | 0xd8 U+fec5 | 0xd8 U+fec7 | | 0xf1 U+0651 | 0xf1 U+fe7c | **Note**: 0x1a <-> U+001c / 0x1c <-> U+007f / 0x7f <-> U+001a entries are control character rotation for DOS. I think it should be ignored. I think, roundtrip side should be changed. 0x25 entry should be U+0025 on IBM864.map Add `0x25 U+066a` into IBM864.c2b Modify test/jdk/sun/nio/cs/mapping/Cp864.b2c for `0025 0025` Add `0025 066a` into test/jdk/sun/nio/cs/mapping/Cp864.c2b-irreversible This issue just for U+0025, but f possible, please add `0x9f, 0xd7, 0xd8, 0xf1` entries. ------------- PR: https://git.openjdk.org/jdk/pull/9661 From naoto at openjdk.org Thu Jul 28 16:22:31 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 28 Jul 2022 16:22:31 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: <0dcA7IfbHxn9XCjncuVEVSoA6jcygKHckFumifkPmuM=.adf1d4ff-dfc0-4f23-bfd2-94b03d773624@github.com> References: <0dcA7IfbHxn9XCjncuVEVSoA6jcygKHckFumifkPmuM=.adf1d4ff-dfc0-4f23-bfd2-94b03d773624@github.com> Message-ID: On Thu, 28 Jul 2022 10:29:07 GMT, Ichiroh Takiguchi wrote: >> @takiguc Sure. Appreciate it. > > Many thanks @naotoj . > > I checked the latest IBM-864 mapping table. > (I assume current OpenJDK's IBM864 may refer older mapping table) > https://raw.githubusercontent.com/unicode-org/icu/main/icu4c/source/data/mappings/ibm-864_X110-1999.ucm > .ucm file format is as follows: > https://unicode-org.github.io/icu/userguide/conversion/data.html#ucm-file-format > > I checked roundtrip mapping > (Roundtrip entries have `|0` at the end of line) > | IBM864.map | ibm-864_X110-1999.ucm | > | --- | --- | > | 0x1a U+001a | 0x1a U+001c | > | 0x1c U+001c | 0x1c U+007f | > | **0x25 U+066a** | **0x25 U+0025** | > | 0x7f U+007f | 0x7f U+001a | > | 0x9f U+fffd | 0x9f U+200b | > | 0xd7 U+fec1 | 0xd7 U+fec3 | > | 0xd8 U+fec5 | 0xd8 U+fec7 | > | 0xf1 U+0651 | 0xf1 U+fe7c | > > **Note**: 0x1a <-> U+001c / 0x1c <-> U+007f / 0x7f <-> U+001a entries are control character rotation for DOS. > I think it should be ignored. > > I think, roundtrip side should be changed. > 0x25 entry should be U+0025 on IBM864.map > Add `0x25 U+066a` into IBM864.c2b > > Modify test/jdk/sun/nio/cs/mapping/Cp864.b2c for `0025 0025` > Add `0025 066a` into test/jdk/sun/nio/cs/mapping/Cp864.c2b-irreversible > > This issue just for U+0025, but f possible, please add `0x9f, 0xd7, 0xd8, 0xf1` entries. Thanks for trying it out @takiguc. However, I am not planning to change any existing mappings because of the obvious compatibility issues. The fix I proposed is safe because it is additional, which used to be unmappable (thus turned into a replacement '?'). ------------- PR: https://git.openjdk.org/jdk/pull/9661 From joehw at openjdk.org Thu Jul 28 18:07:33 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 28 Jul 2022 18:07:33 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote: > Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9661 From duke at openjdk.org Thu Jul 28 19:43:04 2022 From: duke at openjdk.org (Gaurav Chaudhari) Date: Thu, 28 Jul 2022 19:43:04 GMT Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable [v4] In-Reply-To: References: Message-ID: > This is a REDO of the Fix that was incompletely implemented earlier: > [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660) > > Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days. > > I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works: > _(where 7200 represents 7200 seconds -> +2 hour offset)_ > Sample output: > ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png) Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision: 8288377: Adjusted length check for returned gmt-offset ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9312/files - new: https://git.openjdk.org/jdk/pull/9312/files/8ca0a727..b09df3d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9312&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9312&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9312.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9312/head:pull/9312 PR: https://git.openjdk.org/jdk/pull/9312 From naoto at openjdk.org Thu Jul 28 20:54:21 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 28 Jul 2022 20:54:21 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 20:31:44 GMT, Alisen Chung wrote: >> open l10n msg drop >> All tests passed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > removed localized files from base - src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_US.properties: this should not be moved from `java.base` module - I still need some comments explaining `XXX=XXX` in the root bundle of `CurrencyNames`. Something like These currency symbol entries are for the root bundle only to avoid throwing a MissingResourceException. Should not be copied into each localized resource bundle. src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: CNY=\uffe5 Do not remove the original translation. ------------- Changes requested by naoto (Reviewer). PR: https://git.openjdk.org/jdk19/pull/154 From itakiguchi at openjdk.org Fri Jul 29 05:19:31 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Fri, 29 Jul 2022 05:19:31 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: <0dcA7IfbHxn9XCjncuVEVSoA6jcygKHckFumifkPmuM=.adf1d4ff-dfc0-4f23-bfd2-94b03d773624@github.com> Message-ID: On Thu, 28 Jul 2022 16:18:51 GMT, Naoto Sato wrote: >> Many thanks @naotoj . >> >> I checked the latest IBM-864 mapping table. >> (I assume current OpenJDK's IBM864 may refer older mapping table) >> https://raw.githubusercontent.com/unicode-org/icu/main/icu4c/source/data/mappings/ibm-864_X110-1999.ucm >> .ucm file format is as follows: >> https://unicode-org.github.io/icu/userguide/conversion/data.html#ucm-file-format >> >> I checked roundtrip mapping >> (Roundtrip entries have `|0` at the end of line) >> | IBM864.map | ibm-864_X110-1999.ucm | >> | --- | --- | >> | 0x1a U+001a | 0x1a U+001c | >> | 0x1c U+001c | 0x1c U+007f | >> | **0x25 U+066a** | **0x25 U+0025** | >> | 0x7f U+007f | 0x7f U+001a | >> | 0x9f U+fffd | 0x9f U+200b | >> | 0xd7 U+fec1 | 0xd7 U+fec3 | >> | 0xd8 U+fec5 | 0xd8 U+fec7 | >> | 0xf1 U+0651 | 0xf1 U+fe7c | >> >> **Note**: 0x1a <-> U+001c / 0x1c <-> U+007f / 0x7f <-> U+001a entries are control character rotation for DOS. >> I think it should be ignored. >> >> I think, roundtrip side should be changed. >> 0x25 entry should be U+0025 on IBM864.map >> Add `0x25 U+066a` into IBM864.c2b >> >> Modify test/jdk/sun/nio/cs/mapping/Cp864.b2c for `0025 0025` >> Add `0025 066a` into test/jdk/sun/nio/cs/mapping/Cp864.c2b-irreversible >> >> This issue just for U+0025, but f possible, please add `0x9f, 0xd7, 0xd8, 0xf1` entries. > > Thanks for trying it out @takiguc. However, I am not planning to change any existing mappings because of the obvious compatibility issues. The fix I proposed is safe because it is additional, which used to be unmappable (thus turned into a replacement '?'). Hello @naotoj . I checked [JDK-8290488](https://bugs.openjdk.org/browse/JDK-8290488). This issue was tested by Windows 10. I think we need to confirm expected result for b2c side to reporter. I checked MS's 864 via following test program on my Windows 10. >type b2c_1.ps1 param($code, $hex) $h = [string]$hex $enc_r = [Text.Encoding]::GetEncoding([int]$code) [byte[]]$ba = @() for($i = 0; $i -lt $h.length; $i+=2) { $ba += ([System.Convert]::ToInt32($h.SubString($i,2), 16)) } $s = "" $enc_r.GetChars($ba) | foreach {$s += [System.Convert]::ToInt32($_).ToString("X4")} $s >powershell -NoProfile -ExecutionPolicy Unrestricted .\b2c_1.ps1 864 25 0025 Please ignore about 0xD7,0xD8,0xF1 if the target platform is Windows. Note: Test result for c2b side. >type c2b_1.ps1 param($code, $hex) $enc_r = [Text.Encoding]::GetEncoding([int]$code) [char[]]$ca = @() $ca += ([System.Convert]::ToInt32([string]$hex, 16)) $s = "" $enc_r.GetBytes($ca) | foreach {$s += [System.Convert]::ToInt32($_).ToString("X2")} $s >powershell -NoProfile -ExecutionPolicy Unrestricted .\c2b_1.ps1 864 0025 25 >powershell -NoProfile -ExecutionPolicy Unrestricted .\c2b_1.ps1 864 066A 25 ------------- PR: https://git.openjdk.org/jdk/pull/9661 From naoto at openjdk.org Fri Jul 29 16:17:56 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 29 Jul 2022 16:17:56 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: <5TntCtdD8Fbjx1IdZZLmaBFwHiQlFwqP9GX62Wqs-NM=.1dc8c55d-373b-490d-93c1-be18ef2b7847@github.com> On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote: > Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. Sorry, but I don't have any intention to change the current roundtrip behavior of 0x25 <-> U+066A in Cp/IBM864 converter. Changing it to something else will introduce an incompatible behavior with prior JDKs. ------------- PR: https://git.openjdk.org/jdk/pull/9661 From achung at openjdk.org Fri Jul 29 18:13:25 2022 From: achung at openjdk.org (Alisen Chung) Date: Fri, 29 Jul 2022 18:13:25 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: Message-ID: > open l10n msg drop > All tests passed. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/154/files - new: https://git.openjdk.org/jdk19/pull/154/files/6776bd0f..737b253f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=02-03 Stats: 4 lines in 3 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/154.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154 PR: https://git.openjdk.org/jdk19/pull/154 From naoto at openjdk.org Fri Jul 29 18:19:42 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 29 Jul 2022 18:19:42 GMT Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable [v4] In-Reply-To: References: Message-ID: <6yHp_l2cal4zIoIm22BPUjI4yEMRf_DEL4Hzx5UsGbA=.28f5f6ee-f163-4066-a7b7-d333bc17ffe8@github.com> On Thu, 28 Jul 2022 19:43:04 GMT, Gaurav Chaudhari wrote: >> This is a REDO of the Fix that was incompletely implemented earlier: >> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660) >> >> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days. >> >> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works: >> _(where 7200 represents 7200 seconds -> +2 hour offset)_ >> Sample output: >> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png) > > Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision: > > 8288377: Adjusted length check for returned gmt-offset Looks good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/9312 From naoto at openjdk.org Fri Jul 29 23:27:53 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 29 Jul 2022 23:27:53 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v5] In-Reply-To: References: Message-ID: <8Qeairg7kL4tlQ_N55Nhf-pTxDvh4lvgjZ-21Pnd5W0=.c17a9286-5ef3-4642-afd2-59ac552136ae@github.com> > This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Parse invalid fields correctly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9620/files - new: https://git.openjdk.org/jdk/pull/9620/files/e24e5dd8..d3242ba9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=03-04 Stats: 29 lines in 3 files changed: 26 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From joehw at openjdk.org Sat Jul 30 01:43:46 2022 From: joehw at openjdk.org (Joe Wang) Date: Sat, 30 Jul 2022 01:43:46 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v5] In-Reply-To: <8Qeairg7kL4tlQ_N55Nhf-pTxDvh4lvgjZ-21Pnd5W0=.c17a9286-5ef3-4642-afd2-59ac552136ae@github.com> References: <8Qeairg7kL4tlQ_N55Nhf-pTxDvh4lvgjZ-21Pnd5W0=.c17a9286-5ef3-4642-afd2-59ac552136ae@github.com> Message-ID: On Fri, 29 Jul 2022 23:27:53 GMT, Naoto Sato wrote: >> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Parse invalid fields correctly test/jdk/java/util/Locale/bcp47/TExtensionTests.java line 190: > 188: } catch (IllformedLocaleException ile) { > 189: // success > 190: System.out.println("IllformedLocaleException thrown correctly: " + ile.getMessage()); Could use assertThrows, but ok if you want to keep it this way. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From naoto at openjdk.org Sat Jul 30 20:52:49 2022 From: naoto at openjdk.org (Naoto Sato) Date: Sat, 30 Jul 2022 20:52:49 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v6] In-Reply-To: References: Message-ID: > This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Use `assertThrows` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9620/files - new: https://git.openjdk.org/jdk/pull/9620/files/d3242ba9..9f60232e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=04-05 Stats: 16 lines in 1 file changed: 1 ins; 11 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From naoto at openjdk.org Sat Jul 30 20:53:13 2022 From: naoto at openjdk.org (Naoto Sato) Date: Sat, 30 Jul 2022 20:53:13 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v5] In-Reply-To: References: <8Qeairg7kL4tlQ_N55Nhf-pTxDvh4lvgjZ-21Pnd5W0=.c17a9286-5ef3-4642-afd2-59ac552136ae@github.com> Message-ID: <2fKzEh3uQMw9TCOsUKq9aCBINE7WzlFAJbPoas80Tzs=.eee6f0b6-b5c0-46ff-9987-786d9a549f31@github.com> On Sat, 30 Jul 2022 01:39:54 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Parse invalid fields correctly > > test/jdk/java/util/Locale/bcp47/TExtensionTests.java line 190: > >> 188: } catch (IllformedLocaleException ile) { >> 189: // success >> 190: System.out.println("IllformedLocaleException thrown correctly: " + ile.getMessage()); > > Could use assertThrows, but ok if you want to keep it this way. Thanks, Joe. Replaced them with `assertThrows`. ------------- PR: https://git.openjdk.org/jdk/pull/9620