Re: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/the… > > Also, I fixed a couple of spelling mistakes. LGTM for i18n changes. - Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8768
Integrated: 8283698: Refactor Locale constructors used in src/test
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors > (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are > simple replacements to Locale constructors with `Locale.of()` or Locale > constants, such as `Locale.US`. This pull request has now been integrated. Changeset: d6b4693c Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/d6b4693c0527385f8999089b3f8b2120548efecb Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod 8283698: Refactor Locale constructors used in src/test Reviewed-by: iris, joehw - PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Thu, 7 Apr 2022 00:09:58 GMT, Joe Wang wrote:
>> This is a follow-on task after deprecating the Locale constructors
>> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
>> simple replacements to Locale constructors with `Locale.of()` or Locale
>> constants, such as `Locale.US`.
>
> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
>
>> 79:
>> 80: /**
>> 81: * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
>
> Locale.France?
The test code parses the input string (eg. "fr_FR") into 3 elements, `name`,
`country`, and `variant`, then create a `Locale` using those 3 elements.
Changing it to `Locale.FRANCE` does not seem right here.
> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
>
>> 61: Locale.of("it", "IT", "EURO"),
>> 62: Locale.forLanguageTag("de-AT"),
>> 63: Locale.forLanguageTag("fr-CH"),
>
> Use the new factory? Ok not to change as these are tests and there are too
> many of them. It's not deprecated anyways.
`Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it
validates the input language tag, while `Locale.of()` doesn't as well as Locale
constructors.
> test/jdk/java/text/Format/common/Bug6215962.java line 58:
>
>> 56: check(mf1, mf2, false);
>> 57:
>> 58: mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));
>
> Locale.JAPAN?
The test intends to compare the generated `MessageFormat` objects (`mf2` &
`mf1`) from using a constant `Locale.JAPAN` and the factory method. So I
believe leaving it as `Locale.of()` makes sense.
-
PR: https://git.openjdk.java.net/jdk/pull/8130
RFR: 8283698: Refactor Locale constructors used in src/test
This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. - Commit messages: - 8283698: Refactor Locale constructors used in src/test Changes: https://git.openjdk.java.net/jdk/pull/8130/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8130=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283698 Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod Patch: https://git.openjdk.java.net/jdk/pull/8130.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8130/head:pull/8130 PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8284444: Sting typo [v2]
On Wed, 6 Apr 2022 16:48:38 GMT, Daniel Jeliński wrote: >> src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63: >> >>> 61: * http://www.ietf.org/rfc/rfc3454.txt;>RFC 3454. >>> 62: * StringPrep prepares Unicode strings for use in network protocols. >>> 63: * Profiles of StringPrep are set of rules and data according to which >>> the >> >> These also come from the upstream ICU4J project and should be corrected >> there. >> https://github.com/unicode-org/icu/blob/4833cc89b2fae2e8863b46bf1dc785964847e882/icu4j/main/classes/core/src/com/ibm/icu/text/StringPrep.java#L27 > > Thanks, reverted. Also reverted Xalan changes. Good. Thanks for reverting it. - PR: https://git.openjdk.java.net/jdk/pull/8125
Re: RFR: 8284444: Sting typo [v2]
On Wed, 6 Apr 2022 14:12:17 GMT, Daniel Jeliński wrote: >> This patch adds missing `r` in `string`s > > Daniel Jeliński has updated the pull request incrementally with one > additional commit since the last revision: > > Revert liblcms changes src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63: > 61: * http://www.ietf.org/rfc/rfc3454.txt;>RFC 3454. > 62: * StringPrep prepares Unicode strings for use in network protocols. > 63: * Profiles of StringPrep are set of rules and data according to which the These also come from the upstream ICU4J project and should be corrected there. https://github.com/unicode-org/icu/blob/4833cc89b2fae2e8863b46bf1dc785964847e882/icu4j/main/classes/core/src/com/ibm/icu/text/StringPrep.java#L27 - PR: https://git.openjdk.java.net/jdk/pull/8125
Re: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop 10
On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung wrote: > redo of 8280400 I believe `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties` and `test/jdk/sun/text/resources/LocaleData` have to be adjusted according to the l10n changes. - PR: https://git.openjdk.java.net/jdk/pull/8026
Re: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10
On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung wrote: > This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23. LGTM - Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8005
Re: RFR: 8282819: Deprecate Locale class constructors
On Fri, 25 Mar 2022 15:37:36 GMT, Roger Riggs wrote:
>> Proposing to deprecate the constructors in the `java.util.Locale` class.
>> There is already a factory method and a builder to return singletons, so
>> there is no need to have constructors anymore unless one purposefully wants
>> to create `ill-formed` Locale objects, which is discouraged. We cannot
>> terminally deprecate those constructors for the compatibility to serialized
>> objects created with older JDKs. Please see the draft CSR for more detail.
>
> src/java.base/share/classes/java/util/Locale.java line 245:
>
>> 243: * Factory Method
>> 244: *
>> 245: * The method {@link #forLanguageTag} obtains a {@code Locale}
>
> The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like
> the best name for the factory.
> Yes, it already exists and does what's required but you might get better
> uptake with a more natural name.
>
> Some alternatives:
> - `Locale.of("en_US")` - short and conventional
> - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories
> - `Locale.forLanguage("en_US")` - natural but less conventional
I was thinking of a *new* factory method, along the line with Stuart's
suggestion, something like this:
Locale.of(String... elements)
where elements can either `(lang)`, `(lang, ctry)`, `(lang, ctry, vrnt)`, or
`(lang, ctry, vrnt, scpt)`. Either element can be an empty string, but cannot
be null. These elements are *not* language tags, but conventional arguments to
constructors, so it is compatible (and works as a stop-gap) to the old
constructors. This way third parties will not have to deal with the boilerplate
code mentioned above on migration.
-
PR: https://git.openjdk.java.net/jdk/pull/7947
Re: RFR: 8282819: Deprecate Locale class constructors
On Fri, 25 Mar 2022 00:18:54 GMT, Stuart Marks wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. >> There is already a factory method and a builder to return singletons, so >> there is no need to have constructors anymore unless one purposefully wants >> to create `ill-formed` Locale objects, which is discouraged. We cannot >> terminally deprecate those constructors for the compatibility to serialized >> objects created with older JDKs. Please see the draft CSR for more detail. > > src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java > line 375: > >> 373: (locale.getLanguage().isEmpty() ? "und" : >> locale.getLanguage()) + >> 374: (locale.getCountry().isEmpty() ? "" : "-" + >> locale.getCountry()) + >> 375: (locale.getVariant().isEmpty() ? "" : >> "-x-lvariant-" + locale.getVariant())); > > It seems like this snippet (and ones very similar to it) are repeated several > times throughout the JDK code as replacements for the two- and three-arg > constructors. This seems like a fair increase in complexity, and the use of > "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third > party code that uses the Locale constructors replace them with this snippet? > Is there something better that we can provide? True. One solution could be to expose `Locale.getInstance()`, which is currently a package-private static method, for this purpose. Though that means promoting `ill-formed` locale objects which defy some part of the deprecation cause. - PR: https://git.openjdk.java.net/jdk/pull/7947
RFR: 8282819: Deprecate Locale class constructors
Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. - Commit messages: - 8282819: Deprecate Locale class constructors Changes: https://git.openjdk.java.net/jdk/pull/7947/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7947=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282819 Stats: 904 lines in 196 files changed: 74 ins; 22 del; 808 mod Patch: https://git.openjdk.java.net/jdk/pull/7947.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947 PR: https://git.openjdk.java.net/jdk/pull/7947
Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4]
On Wed, 16 Mar 2022 18:31:55 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional > commit since the last revision: > > removed incorrect translation of compiler configuration file LGTM. Thanks for the change. - Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3]
On Mon, 14 Mar 2022 20:39:46 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional > commit since the last revision: > > removed repeated lines from ROOT bundle in CurrencyNames src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct_ja.properties line 1: > 1: # The change to this file (moving ct.properties to ct_ja.properties) does look suspicious. Looks like this is not a translation file, but some kind of a configuration for `javac`. If so, it should not be translated (and translation configuration in the closed repository should exclude this file) - PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional > commit since the last revision: > > moved CurrencyNames changes to jdk.localedata src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP No need for these lines in each localized files, as English bundle contains them. src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP Same here with `de` 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: ADP=ADP and here. - PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment. - PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 `src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties` `src/java.base/share/classes/sun/util/resources/CurrencyNames_ja.properties` `src/java.base/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties` These are part of `jdk.localedata` module. Should be excluded from `java.base` module and apply the diffs to `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_xx.properties` manually. (Note that the first half of it is not necessary when merging). - PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8279918: Fix various doc typos [v2]
On Thu, 13 Jan 2022 10:59:13 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73: >> >>> 71: * will be transparent to the BreakIterator. A sequence of >>> characters will break the >>> 72: * same way it would if any ignore characters it contains are taken >>> out. Break >>> 73: * positions never occur before ignore characters. >> >> "before ignored characters" > > I believe it's the name of a concept, so I will leave it as is: > >> There is one special substitution. If the description defines a >> substitution called "", the expression must be a [] expression, and >> the expression defines a set of characters (the "ignore characters") that >> will be transparent to the BreakIterator. Yes, that is correct. - PR: https://git.openjdk.java.net/jdk/pull/7063
Re: RFR: 8279918: Fix various doc typos [v2]
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, >> please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant >> formatting artefact and thus can be removed. >> - `` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional > commit since the last revision: > > Additional typos Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7063
Integrated: 8273187: jtools tests fail with missing markerName check
On Thu, 16 Sep 2021 01:08:45 GMT, Naoto Sato wrote: > Fixing failing regression tests caused by the JEP 400: UTF-8 by Default. > > `JcmdOutputEncodingTest` test case uses `file.encoding=UTF-8` in `C` locale. > The output from the agent library is in `UTF-8` so it succeeded before the > JEP has been implemented, as System.out used `UTF-8` converter. After the > JEP, it started failing because System.out is using `US-ASCII` which > generates series of '?', ending up with assertion failure in the test. > > The proposed fix is to pass `sun.stdout.encoding=UTF-8` as well as > `file.encoding` so that tool process' System.out is in `UTF-8` as well. This pull request has now been integrated. Changeset: f71df142 Author:Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/f71df142a97f522b40e90c3105e0e5bd8d5af9a2 Stats: 10 lines in 3 files changed: 3 ins; 4 del; 3 mod 8273187: jtools tests fail with missing markerName check Reviewed-by: iris, sspitsyn, joehw - PR: https://git.openjdk.java.net/jdk/pull/5539
RFR: 8273187: jtools tests fail with missing markerName check
Fixing failing regression tests caused by the JEP 400: UTF-8 by Default. `JcmdOutputEncodingTest` test case uses `file.encoding=UTF-8` in `C` locale. The output from the agent library is in `UTF-8` so it succeeded before the JEP has been implemented, as System.out used `UTF-8` converter. After the JEP, it started failing because System.out is using `US-ASCII` which generates series of '?', ending up with assertion failure in the test. The proposed fix is to pass `sun.stdout.encoding=UTF-8` as well as `file.encoding` so that tool process' System.out is in `UTF-8` as well. - Commit messages: - Merge branch 'master' into JDK-8273187 - Reverted command encoding, then modified the test case to use sun.stdout.encoding - Used `transferTo()` - Merge branch 'master' into JDK-8273187 - Nuked UTF-8 conversion in tools - Merge branch 'master' into JDK-8273187 - 8273187: jtools tests fail with missing markerName check Changes: https://git.openjdk.java.net/jdk/pull/5539/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5539=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273187 Stats: 10 lines in 3 files changed: 3 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5539/head:pull/5539 PR: https://git.openjdk.java.net/jdk/pull/5539
Integrated: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed"
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote: > The gist of the issue is that the test case now always creates the boot > classpath with non-ASCII chars appended, because the default encoding is > fixed to UTF-8 with the fix to JDK-8260265. > > On macOS, javaagent tries to load the class with US-ASCII determined by > nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is > always UTF-8 on mac, so no need to use the determined encoding by > nl_langinfo(). > > On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" > locale (which matches the result from nl_langinfo()), so no non-ASCII suffix > was appended to the `boot` path. But now the "defaultEncoding" is always > UTF-8, the setup code appends the non-ASCII suffix, which fails to read in > the native code using iconv with US-ASCII. The setup code should use the > encoding from "sun.jnu.encoding" instead. Actually, the code there was copied > from UnicodeTest.java which was modified with JDK-8260265, so the same fix > needs to be applied. > > Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. > "Uft8" -> "Utf8" This pull request has now been integrated. Changeset: 54dee132 Author:Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/54dee132d1a149165e7478b29b740d086c18c424 Stats: 36 lines in 8 files changed: 5 ins; 16 del; 15 mod 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" Reviewed-by: dholmes, alanb - PR: https://git.openjdk.java.net/jdk/pull/5427
Re: RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed"
On Wed, 8 Sep 2021 23:38:38 GMT, David Holmes wrote: > Pre-existing: The initialization logic in this code is quite odd for the case > when no conversion is necessary (we call `utfInitialize` on every call to > `convertUtf8ToPlatformString`!), but I assume we do not call > `appendBootClassPath` and `appendToClassLoaderSearch` very often? Indeed. I assume those methods are only used on agent startup. - PR: https://git.openjdk.java.net/jdk/pull/5427
Re: RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed"
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote: > The gist of the issue is that the test case now always creates the boot > classpath with non-ASCII chars appended, because the default encoding is > fixed to UTF-8 with the fix to JDK-8260265. > > On macOS, javaagent tries to load the class with US-ASCII determined by > nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is > always UTF-8 on mac, so no need to use the determined encoding by > nl_langinfo(). > > On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" > locale (which matches the result from nl_langinfo()), so no non-ASCII suffix > was appended to the `boot` path. But now the "defaultEncoding" is always > UTF-8, the setup code appends the non-ASCII suffix, which fails to read in > the native code using iconv with US-ASCII. The setup code should use the > encoding from "sun.jnu.encoding" instead. Actually, the code there was copied > from UnicodeTest.java which was modified with JDK-8260265, so the same fix > needs to be applied. > > Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. > "Uft8" -> "Utf8" Hi David, > Doesn't it depend on the OS version and which file system is being used? HFS+ > seems to use UTF-16 Right. I was not clear enough as to `file system encoding`, what I meant was the `sun.jnu.encoding`, which is always `UTF-8` with this change: https://bugs.openjdk.java.net/browse/JDK-8003228 - PR: https://git.openjdk.java.net/jdk/pull/5427
RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed"
The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265. On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo(). On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied. Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8" - Commit messages: - Merge branch 'master' into JDK-8273188 - 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" Changes: https://git.openjdk.java.net/jdk/pull/5427/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5427=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273188 Stats: 36 lines in 8 files changed: 5 ins; 16 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/5427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5427/head:pull/5427 PR: https://git.openjdk.java.net/jdk/pull/5427
Re: RFR: 8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs
On Wed, 1 Sep 2021 17:33:13 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList > java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs. Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5337
Re: Integrated: 8273197: ProblemList 2 jtools tests due to JDK-8273187
On Tue, 31 Aug 2021 19:44:08 GMT, Daniel D. Daugherty wrote: > Trivial fixes to reduce the noise in the JDK18 CI: > JDK-8273197 ProblemList 2 jtools tests due to JDK-8273187 > JDK-8273198 ProblemList > java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 > > These failures happen in Tier5 so I'm ProblemListing them now to give @naotoj > time to > work on the issues introduced by JDK-8260265 UTF-8 by Default. Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5321
Re: RFR: 8272805: Avoid looking up standard charsets [v2]
On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote:
>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>>
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>>
>> This could be done more efficiently(up to x20 time faster) with use of
>> java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>>
>> The later variant also makes the code cleaner, as it is known not to throw
>> UnsupportedEncodingException in contrary to the former variant.
>>
>> This change includes:
>> * demo/utils
>> * jdk.xx packages
>> * Some places were missed in the previous changes. I have found it by
>> tracing the calls to the Charset.forName() by executing tier1,2,3 and
>> desktop tests.
>>
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>>
>> Code excluded in this fix: the Xerces library(should be fixed upstream),
>> J2DBench(should be compatible to 1.4), some code in the network(the change
>> there are not straightforward, will do it later).
>>
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains 14 additional
> commits since the last revision:
>
> - Update the usage of Files.readAllLines()
> - Update datatransfer
> - Merge branch 'master' into standard-encodings-in-non-public-modules
> - Merge branch 'master' into standard-encodings-in-non-public-modules
> - Fix related imports
> - Merge branch 'master' into standard-encodings-in-non-public-modules
> - Cleanup UnsupportedEncodingException
> - Update PacketStream.java
> - Rollback TextTests, should be compatible with jdk1.4
> - Rollback TextRenderTests, should be compatible with jdk1.4
> - ... and 4 more:
> https://git.openjdk.java.net/jdk/compare/c262b06f...e7127644
Looks good.
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/5210
Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884 and JDK-8271456. This change affects
> fewer cases so I fix all "java." modules at once.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be done more efficiently(up to x20 time faster) with use of
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
>
> The later variant also makes the code cleaner, as it is known not to throw
> UnsupportedEncodingException in contrary to the former variant.
>
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
Marked as reviewed by naoto (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5063
Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884 and JDK-8271456. This change affects
> fewer cases so I fix all "java." modules at once.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be done more efficiently(up to x20 time faster) with use of
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
>
> The later variant also makes the code cleaner, as it is known not to throw
> UnsupportedEncodingException in contrary to the former variant.
>
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
+1
-
PR: https://git.openjdk.java.net/jdk/pull/5063
Re: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
On Thu, 5 Aug 2021 21:36:58 GMT, Jonathan Gibbons wrote: >> src/jdk.hotspot.agent/share/man/jhsdb.1 line 1: >> >>> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights >>> reserved. >> >> This seems not correct? > > According to the comments in the makefile > (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the > original Markdown file, so if the year is wrong there, it will be wrong in > the generated nroff file. > > I think it would be incorrect to edit the dates locally in these files, > because they'll just be overwritten when we generate the files again. > Ideally, the dates should be fixed (if necessary) in the Markdown files, but > that seems out of scope for this P1. > > This is "just" an issue with copyright dates in source files ... and yes, > while I know copyright dates are important, this problem is arguably part of > an ongoing more general problem. > > I note that the generated files *do* correctly identify themselves with > `2021` in the visible output generated to the console by the `man` command. Thanks for the explanation, Jon. Fine by me. - PR: https://git.openjdk.java.net/jdk17/pull/303
Re: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the > upstream files. Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/303
Re: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the > upstream files. src/jdk.hotspot.agent/share/man/jhsdb.1 line 1: > 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights > reserved. This seems not correct? - PR: https://git.openjdk.java.net/jdk17/pull/303
Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K
On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang wrote: > More refactoring to limit the scope of `@SuppressWarnings` annotations. > > Sometimes I introduce new methods. Please feel free to suggest method names > you like to use. LGTM. - Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/152
Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. > https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 > The essential change for this JEP, including the `@Deprecate` annotations > and spec change. It also update the default value of the > `java.security.manager` system property to "disallow", and necessary test > change following this update. > 2. > https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 > Manual changes to several files so that the next commit can be generated > programatically. > 3. > https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 > Automatic changes to other source files to avoid javac warnings on > deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is > generated programmatically, see the comment below for more details. If you > are only interested in a portion of the 3rd commit and would like to review > it as a separate file, please comment here and I'll generate an individual > webrev. > > Due to the size of this PR, no attempt is made to update copyright years for > any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system > property is now "disallow", most of the tests calling > `System.setSecurityManager()` need to launched with > `-Djava.security.manager=allow`. This is covered in a different PR at > https://github.com/openjdk/jdk/pull/4071. Reviewed i18n/java.time/charset. They all look good. - Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073
Re: RFR: 8253497: Core Libs Terminology Refresh
On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote:
> This is part of an effort in the JDK to replace archaic/non-inclusive words
> with more neutral terms (see JDK-8253315 for details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Looks good to me.
test/jdk/java/lang/ClassLoader/Assert.java line 65:
> 63:
> 64: int switchSource = 0;
> 65: if (args.length == 0) { // This is the coordinator version
Extra space between "is" and "the."
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: JDK-8241463 Move build tools to respective modules
Hi Magnus, I looked at i18n related changes: make/CopyInterimTZDB.gmk make/ToolsJdk.gmk make/gendata/Gendata-java.base.gmk make/gendata/GendataBreakIterator.gmk make/gendata/GendataTZDB.gmk make/gensrc/GensrcCharacterData.gmk make/gensrc/GensrcEmojiData.gmk They look ok to me. The *.java changes should have copyright year update. As to charsetmapping and cldrconverter, I believe they can reside in java.base, as jdk.charsets and jdk.localedata modules depend on it. Naoto On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so anymore. Instead, the build tools source code should move the the module that needs them. For instance, compilefontconfig should move to java.desktop, etc. There are multiple reasons for this: * Currently we build *all* build tools at once, which mean that we cannot compile java.base until e.g. the compilefontconfig tool is compiled, even though it is not needed. * If a build tool, e.g. compilefontconfig is modified, all build tools are recompiled, which triggers a rebuild of more or less the entire JDK. This makes development of the build tools unnecessary tedious. * When the build tools are modified, the group owning the corresponding module is the proper review instance, not the build team. But since they reside under "make", the review mails often include build-dev, but this is mostly noise for us. With this move, the ownership is made clear. In this patch, I have not modified how and when the build tools are compiled, but this shuffle is the prerequisite for continuing with that in a follow-up patch. I have also moved the build tools to the org.openjdk.buildtools.* package name space (inspired by Skara), instead of the strangely named build.tools.* name space. A few build tools are not moved in this patch. Two of them, charsetmapping and cldrconverter, are shared between two modules. (I think they should move to modules nevertheless, but they need some more thought to make sure I do this right.) The rest are tools that are needed for the build in general, like linking or javadoc support. I'll move this to a better location too, but in a separate patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 /Magnus
hg: jdk8/tl/jdk: 8028368: There is no description whether or not java.util.ResourceBundle is thread-safe
Changeset: 5b5ee2288306 Author:naoto Date: 2013-12-02 11:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b5ee2288306 8028368: There is no description whether or not java.util.ResourceBundle is thread-safe Reviewed-by: okutsu ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PropertyResourceBundle.java ! src/share/classes/java/util/ResourceBundle.java
hg: jdk8/tl/jdk: 8028771: regression test java/util/Locale/LocaleProviders.sh failed
Changeset: 2370d285d08b Author:naoto Date: 2013-11-27 10:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2370d285d08b 8028771: regression test java/util/Locale/LocaleProviders.sh failed Reviewed-by: alanb ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh
hg: jdk8/tl/jdk: 8027930: ResourceBundle test failures in fr locale
Changeset: fb7abd509bd2 Author:naoto Date: 2013-11-07 10:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fb7abd509bd2 8027930: ResourceBundle test failures in fr locale Reviewed-by: smarks ! test/java/util/ResourceBundle/ResourceBundleTest.java ! test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
hg: jdk8/tl/jdk: 8024332: sun/util/resources/en split between rt.jar and localedata.jar
Changeset: 7bfe3da4fad6 Author:naoto Date: 2013-09-11 05:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bfe3da4fad6 8024332: sun/util/resources/en split between rt.jar and localedata.jar Reviewed-by: alanb, erikj ! make/java/java/genlocales.gmk ! make/java/java/localegen.sh ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! make/sun/text/FILES_java.gmk ! make/sun/text/FILES_properties.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template
hg: jdk8/tl/jdk: 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X
Changeset: 883cc296ec89 Author:bchristi Date: 2013-08-02 15:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/883cc296ec89 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X Summary: On Mac, default to UTF-8 if no environmental hints are available Reviewed-by: naoto, ddehaven ! src/solaris/native/java/lang/java_props_md.c + test/java/lang/System/MacEncoding/ExpectedEncoding.java + test/java/lang/System/MacEncoding/MacJNUEncoding.sh + test/java/lang/System/MacEncoding/TestFileEncoding.java - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh
hg: jdk8/tl/jdk: 6609431: (rb) ResourceBundle.getString() returns incorrect value
Changeset: e34e3ddb3cd8 Author:naoto Date: 2013-06-27 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e34e3ddb3cd8 6609431: (rb) ResourceBundle.getString() returns incorrect value Reviewed-by: okutsu, sherman ! src/share/classes/java/util/Properties.java + test/java/util/Properties/Bug6609431.java + test/java/util/Properties/Bug6609431.properties
hg: jdk8/tl/jdk: 8017322: java/util/Currency/PropertiesTest.sh should run exclusively
Changeset: 336e5a862013 Author:naoto Date: 2013-06-26 11:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/336e5a862013 8017322: java/util/Currency/PropertiesTest.sh should run exclusively Reviewed-by: alanb ! test/TEST.ROOT
hg: jdk8/tl/jdk: 8017468: typo in javadoc: ResourceBunlde
Changeset: bb2e67628dc0 Author:naoto Date: 2013-06-24 16:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb2e67628dc0 8017468: typo in javadoc: ResourceBunlde Reviewed-by: okutsu ! src/share/classes/java/util/spi/LocaleServiceProvider.java
hg: jdk8/tl/jdk: 6863624: java/util/Currency/PropertiesTest.sh writable check is incorrect
Changeset: 8b84d557570c Author:naoto Date: 2013-06-21 13:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b84d557570c 6863624: java/util/Currency/PropertiesTest.sh writable check is incorrect Reviewed-by: alanb ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh
hg: jdk8/tl/jdk: 8015960: java/util/Locale/LocaleProviders.java failing again on Windows
Changeset: cadb0ef6e931 Author:naoto Date: 2013-06-11 11:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cadb0ef6e931 8015960: java/util/Locale/LocaleProviders.java failing again on Windows Reviewed-by: alanb ! test/java/util/Locale/LocaleProviders.java
hg: jdk8/tl/jdk: 8013903: Japanese calendar field names are not displayed with -Djava.locale.providers=HOST on Windows
Changeset: 379e1bcae693 Author:naoto Date: 2013-06-04 10:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/379e1bcae693 8013903: Japanese calendar field names are not displayed with -Djava.locale.providers=HOST on Windows Reviewed-by: okutsu ! src/share/classes/java/util/spi/LocaleServiceProvider.java ! src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh
hg: jdk8/tl/jdk: 6251788: (rb) PropertyResourceBundle doesn't document exceptions
Changeset: b99d56d1aa3f Author:naoto Date: 2013-05-28 14:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b99d56d1aa3f 6251788: (rb) PropertyResourceBundle doesn't document exceptions Reviewed-by: okutsu ! src/share/classes/java/util/PropertyResourceBundle.java
hg: jdk8/tl/jdk: 7056126: DateFormatSymbols documentation has incorrect description about DateFormat; ...
Changeset: 50fde3eeb48c Author:naoto Date: 2013-05-22 16:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50fde3eeb48c 7056126: DateFormatSymbols documentation has incorrect description about DateFormat 7083668: Sample code in ListResourceBundle is still not correct Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/util/ListResourceBundle.java
hg: jdk8/tl/jdk: 8013086: NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied
Changeset: e30396e22c6f Author:naoto Date: 2013-05-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e30396e22c6f 8013086: NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh
hg: jdk8/tl/jdk: 8010666: Implement Currency/LocaleNameProvider in Windows Host LocaleProviderAdapter
Changeset: 62fb9e2b5da1 Author:naoto Date: 2013-04-22 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62fb9e2b5da1 8010666: Implement Currency/LocaleNameProvider in Windows Host LocaleProviderAdapter Reviewed-by: okutsu ! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh
hg: jdk8/tl/jdk: 7091601: Arabic Locale: can not set type of digit in application level
Changeset: 9a6ef3391f32 Author:naoto Date: 2013-04-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a6ef3391f32 7091601: Arabic Locale: can not set type of digit in application level Reviewed-by: okutsu ! src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
hg: jdk8/tl/jdk: 8008576: Calendar mismatch using Host LocaleProviderAdapter
Changeset: d79503c4c56f Author:naoto Date: 2013-03-14 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d79503c4c56f 8008576: Calendar mismatch using Host LocaleProviderAdapter Reviewed-by: okutsu ! make/java/java/FILES_java.gmk ! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/sun/util/locale/LanguageTag.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/CalendarProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + src/share/classes/sun/util/spi/CalendarProvider.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
hg: jdk8/tl/jdk: 8004240: Return value from getAdapterPrefence() can be modified
Changeset: 1a2e59d19d3e Author:naoto Date: 2013-03-04 20:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a2e59d19d3e 8004240: Return value from getAdapterPrefence() can be modified Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + test/java/util/Locale/Bug8004240.java
hg: jdk8/tl/jdk: 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono
Changeset: 79d7595abe95 Author:naoto Date: 2013-02-08 09:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79d7595abe95 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java + test/java/util/Calendar/Bug8007038.java
hg: jdk8/tl/jdk: 7162007: Clean up i18n related caches
Changeset: 1d7a6adf499f Author:naoto Date: 2013-01-14 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d7a6adf499f 7162007: Clean up i18n related caches Reviewed-by: okutsu, ohair ! make/java/java/FILES_java.gmk ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + src/share/classes/sun/util/locale/provider/ResourceBundleBasedAdapter.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java
hg: jdk8/tl/jdk: 8005962: TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments
Changeset: c622df692bfb Author:bchristi Date: 2013-01-10 10:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c622df692bfb 8005962: TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments Summary: Test script now sets LC_ALL, other small changes, relocate test Reviewed-by: naoto, alanb + test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java + test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh - test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java - test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh
hg: jdk8/tl/jdk: 8003228: (props) sun.jnu.encoding should be set to UTF-8 [macosx]
Changeset: dbc692ea3f0a Author:bchristi Date: 2013-01-07 13:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dbc692ea3f0a 8003228: (props) sun.jnu.encoding should be set to UTF-8 [macosx] Summary: Hard-code sun.jnu.encoding to UTF-8 on Mac Reviewed-by: naoto ! src/share/native/java/lang/System.c ! src/solaris/native/java/lang/java_props_md.c + test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java + test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh
hg: jdk8/tl/jdk: 7199750: Loading sequence of service provider is changed
Changeset: 64a42798ea5e Author:naoto Date: 2012-11-15 20:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64a42798ea5e 7199750: Loading sequence of service provider is changed Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/barprovider.jar ! test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java
hg: jdk8/tl/jdk: 8001440: CLDR adapter: Invalid number extension in language tag causes exception in NumberFormat.format()
Changeset: 6420fcd61c10 Author:naoto Date: 2012-11-01 13:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6420fcd61c10 8001440: CLDR adapter: Invalid number extension in language tag causes exception in NumberFormat.format() Reviewed-by: okutsu ! src/share/classes/java/text/DecimalFormatSymbols.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh
hg: jdk8/tl/jdk: 8000997: Multiple locale sensitive services cannot be loaded
Changeset: 7fa45c455034 Author:naoto Date: 2012-10-29 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fa45c455034 8000997: Multiple locale sensitive services cannot be loaded Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider
hg: jdk8/tl/jdk: 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't work as expected with custom extensions; ...
Changeset: 32452042b781 Author:naoto Date: 2012-10-16 10:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32452042b781 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't work as expected with custom extensions 8000273: java.util.Locale.getDisplayVariant(Locale l) isn't transferred to the custom service provider 8000615: JRE adapter: timezone name of en_US is changed when extension directory is added Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java
hg: jdk8/tl/jdk: 7200341: DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some circumstances
Changeset: c725ce4bbf12 Author:naoto Date: 2012-10-09 09:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c725ce4bbf12 7200341: DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some circumstances Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java
hg: jdk8/tl/jdk: 7196799: CLDR adapter can not be invoked when region code is specified in Locale; ...
Changeset: c6a0b13e6efa Author:naoto Date: 2012-10-04 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6a0b13e6efa 7196799: CLDR adapter can not be invoked when region code is specified in Locale 7197573: java/util/Locale/LocaleProviders.sh failed. Reviewed-by: okutsu ! make/java/java/FILES_java.gmk ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java + src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh
hg: jdk8/tl/jdk: 2 new changesets
Changeset: cd4f181eb666 Author:naoto Date: 2012-10-04 21:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd4f181eb666 7200119: Collator.getAvailableLocales() doesn't return Locale.US Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java + test/java/text/Collator/Bug7200119.java Changeset: 647424d6cf65 Author:naoto Date: 2012-10-04 21:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/647424d6cf65 Merge
hg: jdk8/tl/jdk: 7198984: Add java/text/Bidi/Bug6665028.java to ProblemList.txt
Changeset: 0136fca60652 Author:naoto Date: 2012-09-18 10:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0136fca60652 7198984: Add java/text/Bidi/Bug6665028.java to ProblemList.txt Reviewed-by: alanb Contributed-by: yiming.w...@oracle.com ! test/ProblemList.txt
hg: jdk8/tl/jdk: 7193601: Build breakage with the fix to 6336885 (build-infra build)
Changeset: faf4528aea4e Author:naoto Date: 2012-08-24 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/faf4528aea4e 7193601: Build breakage with the fix to 6336885 (build-infra build) Reviewed-by: mduigou ! makefiles/CompileJavaClasses.gmk
hg: jdk8/tl/jdk: 7156459: Remove unnecessary get() from Currency.getInstance()
Changeset: b15db7ded589 Author:naoto Date: 2012-03-27 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b15db7ded589 7156459: Remove unnecessary get() from Currency.getInstance() Reviewed-by: chegar, dholmes, mduigou ! src/share/classes/java/util/Currency.java
hg: jdk8/tl/jdk: 7145454: JVM wide monitor lock in Currency.getInstance(String)
Changeset: 4a5817f9e249 Author:naoto Date: 2012-03-21 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a5817f9e249 7145454: JVM wide monitor lock in Currency.getInstance(String) Reviewed-by: okutsu ! src/share/classes/java/util/Currency.java
hg: jdk8/tl/jdk: 4808233: Locale not thread-safe
Changeset: c647ebb3c4f7 Author:naoto Date: 2011-12-13 15:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c647ebb3c4f7 4808233: Locale not thread-safe Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java
hg: jdk8/tl/jdk: 7117469: Warning cleanup for j.u.Currency and j.u.Locale related classes
Changeset: 85363edbc92f Author:naoto Date: 2011-12-05 17:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85363edbc92f 7117469: Warning cleanup for j.u.Currency and j.u.Locale related classes Reviewed-by: okutsu, smarks ! src/share/classes/java/util/Currency.java ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! src/share/classes/sun/util/resources/LocaleData.java
hg: jdk8/tl/jdk: 7117465: Warning cleanup for IMF classes
Changeset: 42532a097816 Author:naoto Date: 2011-12-02 16:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42532a097816 7117465: Warning cleanup for IMF classes Reviewed-by: okutsu ! src/share/classes/java/awt/im/InputMethodHighlight.java ! src/share/classes/sun/awt/im/CompositionArea.java ! src/share/classes/sun/awt/im/CompositionAreaHandler.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/awt/im/InputMethodContext.java ! src/share/classes/sun/awt/im/InputMethodJFrame.java ! src/share/classes/sun/awt/im/InputMethodManager.java ! src/share/classes/sun/awt/im/SimpleInputMethodWindow.java
hg: jdk8/tl/jdk: 7027061: Testcase failure: java/util/Locale/Bug6989440.java - java.util.ConcurrentModificationException
Changeset: 829c3a8d23fa Author:naoto Date: 2011-10-12 12:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/829c3a8d23fa 7027061: Testcase failure: java/util/Locale/Bug6989440.java - java.util.ConcurrentModificationException Reviewed-by: dholmes, chegar ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! test/java/util/Locale/Bug6989440.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: c3a8d5feee94 Author:naoto Date: 2011-08-17 11:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3a8d5feee94 7073906: Locale.getDefault() returns wrong Locale for Java SE 7 Reviewed-by: okutsu ! src/windows/native/java/lang/java_props_md.c Changeset: f59c83f515e6 Author:naoto Date: 2011-08-17 11:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f59c83f515e6 7079486: Locale.getDisplayScript() (no args) does not honor default DISPLAY locale Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleCategory.java ! test/java/util/Locale/LocaleCategory.sh
hg: jdk8/tl/jdk: 7022407: Spinning CPU in LocaleObjectCache.get()
Changeset: 42fe05e54e69 Author:naoto Date: 2011-07-12 10:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42fe05e54e69 7022407: Spinning CPU in LocaleObjectCache.get() Reviewed-by: okutsu ! src/share/classes/sun/util/locale/LocaleObjectCache.java
hg: jdk7/tl/jdk: 7041950: Fix copyright
Changeset: 05939afe3fc2 Author:naoto Date: 2011-05-09 13:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05939afe3fc2 7041950: Fix copyright Reviewed-by: okutsu ! src/share/classes/sun/text/resources/BreakIteratorRules_th.java
hg: jdk7/tl/jdk: 7031546: test/java/util/ResourceBundle/Bug4168625Test.java fails on solaris10u9 sparc.
Changeset: ea45b4ed1758 Author:naoto Date: 2011-04-06 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea45b4ed1758 7031546: test/java/util/ResourceBundle/Bug4168625Test.java fails on solaris10u9 sparc. Reviewed-by: okutsu ! test/java/util/ResourceBundle/Bug4168625Test.java
hg: jdk7/tl/jdk: 7023613: (lc) Incorrect string returned by Locale.toString() with non-empty script field
Changeset: 8216ad5fabb8 Author:naoto Date: 2011-03-11 11:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8216ad5fabb8 7023613: (lc) Incorrect string returned by Locale.toString() with non-empty script field Reviewed-by: srl ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleEnhanceTest.java
hg: jdk7/tl/langtools: 6875847: Java Locale Enhancement
Changeset: ecff24121064 Author:naoto Date: 2010-08-25 15:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ecff24121064 6875847: Java Locale Enhancement Summary: Fix for javac to allow sun.util.locale package accessible. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/resources/legacy.properties
