On Tue, 1 Mar 2022 11:22:35 GMT, Lance Andersen wrote:
> Are there any TCK tests that need to be modified or Added? I made a very
> quick scan of the open/test/jdk/java/time/tck/java/time/ dirs and did not see
> any tests but of course I could have missed it
There are test cases in the `TCK`
On Tue, 1 Mar 2022 01:47:45 GMT, Joe Wang wrote:
> Was the following assessment in the bug report correct? "the symbol F in
> java.time.DateTimeFormatter is no use in any pattern. It just may cause an
> exception."
No, not correct. It is currently incorrectly tied with the
Fixing the definition and implementation of the pattern symbol `F`. Although it
is an incompatible change, I believe it is worth the fix. For that, a CSR has
been drafted.
-
Commit messages:
- 8282081: java.time.DateTimeFormatter: wrong definition of symbol F
Changes:
On Fri, 25 Feb 2022 19:02:55 GMT, Naoto Sato wrote:
> Refactoring `java.time.ZoneId` class to be a sealed class. A CSR has also
> been drafted.
This pull request has now been integrated.
Changeset: 0ae3d1d5
Author: Naoto Sato
URL:
https://git.openjdk.java.net/jdk/
Refactoring `java.time.ZoneId` class to be a sealed class. A CSR has also been
drafted.
-
Commit messages:
- 8282131: java.time.ZoneId should be a sealed abstract class
Changes: https://git.openjdk.java.net/jdk/pull/7625/files
Webrev:
On Fri, 25 Feb 2022 03:51:09 GMT, Jaikiran Pai wrote:
>> test/jdk/java/util/Properties/PropertiesStoreTest.java line 112:
>>
>>> 110: locales.add(Locale.getDefault()); // always test the default
>>> locale
>>> 111: locales.add(Locale.US); // guaranteed to be present
>>> 112:
On Fri, 25 Feb 2022 03:54:32 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test only change which fixes the issue
>> noted in https://bugs.openjdk.java.net/browse/JDK-8282023?
>>
>> As noted in that JBS issue these tests fail when the default locale under
>> which those tests
On Thu, 24 Feb 2022 05:02:47 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test only change which fixes the issue
>> noted in https://bugs.openjdk.java.net/browse/JDK-8282023?
>>
>> As noted in that JBS issue these tests fail when the default locale under
>> which those tests
On Wed, 23 Feb 2022 21:51:50 GMT, Roger Riggs wrote:
>> src/java.base/unix/native/libjava/java_props_md.c line 498:
>>
>>> 496: if ((user_home != NULL) && (user_home[0] != '\0')) {
>>> 497: sprops.user_home = user_home;
>>> 498: }
>>
>> Is there any
On Wed, 23 Feb 2022 22:00:19 GMT, Roger Riggs wrote:
>> In some Linux configurations, the Linux home directory provided by getpwent
>> is not usable.
>> The value of the system property `user.home` should fallback to the value of
>> $HOME
>> if getpwent.user_home is null or less that 2
On Fri, 18 Feb 2022 15:29:34 GMT, Roger Riggs wrote:
> In some Linux configurations, the Linux home directory provided by getpwent
> is not usable.
> The value of the system property `user.home` should fallback to the value of
> $HOME
> if getpwent.user_home is null or less that 2 characters
On Wed, 23 Feb 2022 01:08:21 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test only change which fixes the issue
>> noted in https://bugs.openjdk.java.net/browse/JDK-8282023?
>>
>> As noted in that JBS issue these tests fail when the default locale under
>> which those tests
On Mon, 21 Feb 2022 14:09:50 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test only change which fixes the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8282023?
>
> As noted in that JBS issue these tests fail when the default locale under
> which those tests are
On Fri, 18 Feb 2022 20:54:24 GMT, Tyler Steele wrote:
>> FileEncodingTest expects all non-Windows platforms will have
>> `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set
>> to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1.
>>
>> According to
On Fri, 18 Feb 2022 19:50:33 GMT, Tyler Steele wrote:
>> FileEncodingTest expects all non-Windows platforms will have
>> `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set
>> to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1.
>>
>> According to
On Fri, 18 Feb 2022 19:06:28 GMT, Tyler Steele wrote:
>> FileEncodingTest expects all non-Windows platforms will have
>> `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set
>> to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1.
>>
>> According to
On Thu, 17 Feb 2022 22:50:37 GMT, Tyler Steele wrote:
> FileEncodingTest expects all non-Windows platforms will have
> `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set
> to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1.
>
> According to
On Thu, 17 Feb 2022 07:32:36 GMT, Selikoff wrote:
> Can I please be added as a Reviewer? I was the one who originally reported
> this bug on 2/7/2022 via Oracle's web form.
To be listed as a Reviewer, you will need to be a Reviewer of the JDK Project
On Wed, 9 Feb 2022 22:37:45 GMT, Naoto Sato wrote:
> Fixing an issue in `CompactNumberFormat` which was caused by
> BigDecimal.divide() that incremented the number in the resulting format
> string. Also fixing some typos by taking this opportunity.
This pull request has now been i
On Wed, 16 Feb 2022 22:41:40 GMT, Ian Graves wrote:
>> This is a fix in the buggy way CIBackRef traverses unicode characters that
>> could be variable-length. Originally it followed the approach that BackRef
>> does, but failed to account for unicode characters that could be 2
>> chars-long.
On Wed, 16 Feb 2022 18:45:29 GMT, Ian Graves wrote:
> This is a fix in the buggy way CIBackRef traverses unicode characters that
> could be variable-length. Originally it followed the approach that BackRef
> does, but failed to account for unicode characters that could be 2
> chars-long. The
On Thu, 3 Feb 2022 23:29:54 GMT, Naoto Sato wrote:
> Following the prior discussion [1], here is the PR for the subject
> enhancement. CSR has also been updated according to the suggestion.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.
On Tue, 15 Feb 2022 21:59:42 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressing review comments
>
> src/java.base/share/classes/java/text/CompactNumberF
> Fixing an issue in `CompactNumberFormat` which was caused by
> BigDecimal.divide() that incremented the number in the resulting format
> string. Also fixing some typos by taking this opportunity.
Naoto Sato has updated the pull request incrementally with one additional
commit since
Fixing an issue in `CompactNumberFormat` which was caused by
BigDecimal.divide() that incremented the number in the resulting format string.
Also fixing some typos by taking this opportunity.
-
Commit messages:
- 8281317: CompactNumberFormat displays 4-digit values when rounding
On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
>
> The commit introduces the missing `err.invalid.filters` key in the jdeps
> resource bundle. I have
On Fri, 11 Feb 2022 22:26:03 GMT, Roger Riggs wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressing review comments
>
> src/java.base/share/classes/java/time/format/DateTimeForm
> Following the prior discussion [1], here is the PR for the subject
> enhancement. CSR has also been updated according to the suggestion.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
Naoto Sato has updated the pull request increme
On Thu, 10 Feb 2022 22:20:48 GMT, Roger Riggs wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate
>
> src/java.base
> Following the prior discussion [1], here is the PR for the subject
> enhancement. CSR has also been updated according to the suggestion.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
Naoto Sato has updated the pull request increme
> Following the prior discussion [1], here is the PR for the subject
> enhancement. CSR has also been updated according to the suggestion.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
Naoto Sato has updated the pull request increme
On Mon, 7 Feb 2022 21:22:12 GMT, Roger Riggs wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Modified per suggestions on the PR
>
> src/java.base/share/classes/java/time/format/DateTim
On Tue, 8 Feb 2022 00:39:04 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Modified per suggestions on the PR
>
> src/java.base/share/classes/java/time/format/DateTimeFor
> Following the prior discussion [1], here is the PR for the subject
> enhancement. CSR has also been updated according to the suggestion.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
Naoto Sato has updated the pull request increme
Following the prior discussion [1], here is the PR for the subject enhancement.
CSR has also been updated according to the suggestion.
[1]
https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
-
Commit messages:
- Removed trailing space
- Merge branch
On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy wrote:
> The references to JOSS, the Java Object Serialization Specification, are not
> done consistently in the API javadoc. This should be improved.
>
> I'll update copyright years before pushing.
Marked as reviewed by naoto (Reviewer).
On Mon, 31 Jan 2022 20:01:39 GMT, Roger Riggs wrote:
>> During deserialization of a serialized data stream that contains a proxy
>> descriptor with non-public interfaces
>> `java.io.ObjectInputStream` checks that the interfaces can be loaded from a
>> single classloader in
On Fri, 28 Jan 2022 21:02:23 GMT, Roger Riggs wrote:
> During deserialization of a serialized data stream that contains a proxy
> descriptor with non-public interfaces
> `java.io.ObjectInputStream` checks that the interfaces can be loaded from a
> single classloader in
Updated the CSR based on your inputs.
On 1/27/22 2:34 PM, Stephen Colebourne wrote:
On Thu, 27 Jan 2022 at 19:23, Naoto Sato wrote:
Now come to think of it, I came up with the draft based on `ofPattern()`
methods. One of them is a overload method that takes a Locale argument.
Why is it so
On Wed, 26 Jan 2022 20:05:07 GMT, Joe Darcy wrote:
> The changes in this PR on top of the out-for-review changes in
> https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint
> checking to be enabled in all JDK modules.
>
> Typically, a @SuppressWarnings("doclint:refernce")
Hi Stephen,
On 1/27/22 1:00 AM, Stephen Colebourne wrote:
Hi,
This would be a useful addition. Some comments:
There is no need for the method overload that takes Locale. The other
similar methods all operate using the locale of the formatter, and
have this Javadoc:
* The locale is
Hi Joe,
On 1/24/22 5:50 PM, Joe Wang wrote:
The 2nd and 3rd statements defined the requestedTemplate, does
it imply the characters listed in the snippet are the only ones that are
valid, in other words, can other characters under the Patterns section
be used? It may be helpful to
Updated the CSR (https://bugs.openjdk.java.net/browse/JDK-8243445), by
adding a regular expression for the requested template. This way, it is
less depending on the LDML specification.
Naoto
On 1/21/22 2:39 PM, Naoto Sato wrote:
Thanks, Joe.
Good point. I will elaborate the pattern template
On Mon, 24 Jan 2022 17:21:57 GMT, Ian Graves wrote:
> Replacing a buggy NullPointerException in `Pattern.compile()` with the proper
> PatternSyntaxException
Marked as reviewed by naoto (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7201
out having
to consult the LDML specification. Some comparison with the ofPattern
methods might also be helpful.
Just my 2 cents.
Thanks,
Joe
On 1/20/22 1:46 PM, Naoto Sato wrote:
Hello,
I am proposing a couple of new factory methods in
java.time.format.DateTimeFormatter that produce flexible local
On Fri, 21 Jan 2022 19:28:21 GMT, Daniel Jeliński wrote:
> Reported by clang-tidy. Verified manually by running
>
> Calendar c = Calendar.getInstance();
> System.out.println (c.getDisplayNames(Calendar.MONTH,
> Calendar.SHORT_STANDALONE, Locale.getDefault()));
>
> with
On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote:
> Parameter `ChronoField field` is checked by `if (field instanceof
> ChronoField)`. Such check is confusing, because only one case, when this
> could be `false` is when `field == null`.
> But if condition is not satisfied we will get
Hello,
I am proposing a couple of new factory methods in
java.time.format.DateTimeFormatter that produce flexible localized
date/time formats, other than the existing pre-defined
(FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a year
and month only string, such as the title
On Tue, 18 Jan 2022 16:27:11 GMT, Claes Redestad wrote:
>> This resolves minor inefficiency in the fast-path for decoding latin-1 chars
>> from UTF-8. I also took the opportunity to refactor the StringDecode
>> microbenchmark to align with recent changes to the StringEncode micro.
>>
>> The
On Thu, 13 Jan 2022 21:52:59 GMT, Naoto Sato wrote:
> 8278434: timeouts in test
> java/time/test/java/time/format/TestZoneTextPrinterParser.java
This pull request has now been integrated.
Changeset: 064ee6ae
Author: Naoto Sato
URL:
https://git.openjdk.java.net/jdk18/
8278434: timeouts in test
java/time/test/java/time/format/TestZoneTextPrinterParser.java
-
Commit messages:
- Backport 8dc4437d002db5d025b47f48e7420e3bae55bdec
Changes: https://git.openjdk.java.net/jdk18/pull/100/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk18=100=00
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
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
On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote:
> Please review the changes for upgrading the Unicode support in the JDK, from
> version 13 to version 14. Corresponding CSR has also been drafted.
This pull request has now been integrated.
Changeset: 0a094d7c
Author: Naoto Sat
Please review the changes for upgrading the Unicode support in the JDK, from
version 13 to version 14. Corresponding CSR has also been drafted.
-
Commit messages:
- Amend unicode.md and icu.md files
- Minor fixup
- Merge branch 'master' into unicode
- Copyright year to 2022
-
On Fri, 10 Dec 2021 00:27:25 GMT, Naoto Sato wrote:
> The proposed fix is to address the performance degradation caused by the fix
> to JDK-8275721. Some amount of the degradation cannot be avoided as the
> lookup now falls back up to the bundles at Locale.ROOT. However, by
On Mon, 3 Jan 2022 23:45:16 GMT, Joe Wang wrote:
> Hope looping through Zone strings isn't really necessary.
Thanks, Joe. IMHO, `DateFormatSymbols.getZoneStrings()` is badly designed. It
just simply exposes the names in the underlying ResourceBundle, and I cannot
think of any use cases for
5 ± 0.696 s/op
>
> Before the proposed fix:
>
> BenchmarkMode Cnt Score Error Units
> ZoneStrings.testZoneStringsss5 15.741 ± 4.300 s/op
>
> After the proposed fix:
>
> BenchmarkMode Cnt Score Error Units
> Z
On Wed, 22 Dec 2021 07:33:55 GMT, Daniel Le wrote:
>> Locale.filterTags methods ignore actual weight when matching "*" (as if
>> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
>>
>> Fix the bug and add regression test cases for it as well as existing
>> behavior.
>
> Daniel
On Fri, 10 Dec 2021 00:02:31 GMT, Daniel Le wrote:
> Locale.filterTags methods ignore actual weight when matching "*" (as if
> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
>
> Fix the bug and add regression test cases for it as well as existing
> behavior.
Thanks for the
On Fri, 17 Dec 2021 13:41:17 GMT, Naoto Sato wrote:
> 8278587: StringTokenizer(String, String, boolean) documentation bug
This pull request has now been integrated.
Changeset: 9cd70906
Author: Naoto Sato
URL:
https://git.openjdk.java.net/jdk18/com
8278587: StringTokenizer(String, String, boolean) documentation bug
-
Commit messages:
- Backport 8f5fdd864b6f1cf4a2d9d961d8d4118960f0751e
Changes: https://git.openjdk.java.net/jdk18/pull/43/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk18=43=00
Issue:
On Tue, 14 Dec 2021 18:25:45 GMT, Naoto Sato wrote:
> This is a doc fix to `StringTokenizer`, where the original spec does not
> account for the delimiter's length in the case of a supplementary character.
> Corresponding CSR has been drafted:
> https://bugs.openjdk.java.ne
The proposed fix is to address the performance degradation caused by the fix to
JDK-8275721. Some amount of the degradation cannot be avoided as the lookup now
falls back up to the bundles at Locale.ROOT. However, by lowering the fallback
priority of `regionFormatFallback` than `COMPAT`'s
> This is a doc fix to `StringTokenizer`, where the original spec does not
> account for the delimiter's length in the case of a supplementary character.
> Corresponding CSR has been drafted:
> https://bugs.openjdk.java.net/browse/JDK-8278814
Naoto Sato has updated the
On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad wrote:
> A few refactorings to how `java.util.Formatter` sets up `FormatString`s,
> aligning the implementation with changes explored by the TemplatedStrings JEP
> and ever so slightly improving performance:
>
> - turn `Flags` into an `int`
This is a doc fix to `StringTokenizer`, where the original spec does not
account for the delimiter's length in the case of a supplementary character.
Corresponding CSR has been drafted:
https://bugs.openjdk.java.net/browse/JDK-8278814
-
Commit messages:
- 8278587:
On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs wrote:
> Compilation warnings of the test library introduce noise in test output and
> should be addressed or suppressed.
> Changes include:
> - SuppressWarnings("deprecation") and SuppressWarnings("removal")
> - Adding type parameters to Raw
On Fri, 3 Dec 2021 12:35:22 GMT, Jim Laskey wrote:
>> Toshio Nakamura has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changed testcase name to JImageNonAsciiNameTest.java
>
> Change looks reasonable. A regression test should be
On Mon, 6 Dec 2021 18:52:51 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use isFixedOffset() instead of useDaylightTime()
>
> src/java.ba
`zh-MO` name retrieval.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Removed unused import
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6709/files
- new: https://git.openjdk.java.net/jdk/pull/6709/fi
On Fri, 3 Dec 2021 07:29:17 GMT, Toshio Nakamura wrote:
> Could you review this fix?
>
> Problem:
> Custom JRE generated by jlink cannot find non-ASCII named modules included
> inside the JRE.
>
> Cause and fix:
> If module or package name was composed by ASCII then non-ASCII characters,
>
`zh-MO` name retrieval.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Use isFixedOffset() instead of useDaylightTime()
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6709/files
- new: https://git.openjdk.
`zh-MO` name retrieval.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Fixed COMPAT substitution for FULL names and modified the priority.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6709/files
Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display
names were incorrectly substituted for CLDR. The reason it worked fine after
`zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for
`zh-Hant` were cached and hit for the following `zh-MO` name
On Wed, 1 Dec 2021 18:33:44 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review this patch to address a failure at DST->STD offset transition.
> The fix mirrors what was done for JDK-8190748
>
>
> Best,
> Lance
Looks good, Lance. I'd add `noreg-self` label to the JIRA issue.
On Tue, 23 Nov 2021 17:00:58 GMT, Naoto Sato wrote:
> This fix intends to honor the type (std/dst/generic) of parsed zone name for
> selecting the offset at the overlap. Corresponding CSR has also been drafted.
This pull request has now been integrated.
Changeset: a363b7b9
Author:
On Mon, 29 Nov 2021 18:48:45 GMT, Naoto Sato wrote:
> Fixing tests that fail at DST->STD offset transition. Simply skipping the
> tests on that occasion.
This pull request has now been integrated.
Changeset: f1c20e91
Author: Naoto Sato
URL:
https://git.openjdk.java.net/j
On Tue, 30 Nov 2021 18:53:26 GMT, Joe Wang wrote:
> The result of Util.baseName(systemId) can be empty, causing the compiler to
> set an empty classname. Add a check to make sure it will not set the empty
> classname.
>
> Alternatively, it may report an error, but that would be disruptive. As
> Fixing tests that fail at DST->STD offset transition. Simply skipping the
> tests on that occasion.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Changed to not skipping the test in DateFormatTest.java
-
On Mon, 29 Nov 2021 21:09:47 GMT, Lance Andersen wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Changed to not skipping the test in DateFormatTest.java
>
> test/jdk/java/text/Format/
Fixing tests that fail at DST->STD offset transition. Simply skipping the tests
on that occasion.
-
Commit messages:
- 8190748: java/text/Format/DateFormat/DateFormatTest.java and
NonGregorianFormatTest fail intermittently
Changes: https://git.openjdk.java.net/jdk/pull/6598/files
On Thu, 25 Nov 2021 08:26:56 GMT, Stephen Colebourne
wrote:
>> Naoto Sato has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Replaced integer literals.
>> - Refined wording #2
>
> src/java
> This fix intends to honor the type (std/dst/generic) of parsed zone name for
> selecting the offset at the overlap. Corresponding CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Refined wording. R
On Wed, 24 Nov 2021 21:27:15 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refined wording
>
> src/java.base/share/classes/java/time/format/DateTimeFormatter.java line
> This fix intends to honor the type (std/dst/generic) of parsed zone name for
> selecting the offset at the overlap. Corresponding CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with two additional
commits since the last revision:
- Replaced integer li
On Tue, 23 Nov 2021 23:50:36 GMT, Naoto Sato wrote:
>> This fix intends to honor the type (std/dst/generic) of parsed zone name for
>> selecting the offset at the overlap. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally w
> This fix intends to honor the type (std/dst/generic) of parsed zone name for
> selecting the offset at the overlap. Corresponding CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Refined w
This fix intends to honor the type (std/dst/generic) of parsed zone name for
selecting the offset at the overlap. Corresponding CSR has also been drafted.
-
Commit messages:
- 8177819: DateTimeFormatterBuilder zone parsing should recognise DST
Changes:
On Fri, 19 Nov 2021 20:47:40 GMT, Roger Riggs wrote:
>> The `jdk.internal.ValueBased` annotation was incorrectly applied to
>> subclasses of java.util.AbstractMap.
>> [ValueBased](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/doc-files/ValueBased.html)
>> requires that
On Thu, 18 Nov 2021 23:43:20 GMT, Joe Wang wrote:
>> Add setProperty/getProperty methods to the XPath API so that properties can
>> be supported in the future.
>
> Joe Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update as
On Sun, 14 Nov 2021 16:45:07 GMT, Ichiroh Takiguchi
wrote:
>> Good suggestions. Filed a JBS issue:
>> https://bugs.openjdk.java.net/browse/JDK-8276970
>
> Hello @naotoj .
> For PrintStream.getCharset(), following changes may be required.
>
> +++
On Thu, 18 Nov 2021 15:33:26 GMT, Roger Riggs wrote:
>> The ObjectInputStream.GetField.get(String name, Object val) method is
>> returning null instead of throwing an exception when the class of the object
>> is not found. The caller is not able to correctly handle the case where the
>> class
On Wed, 10 Nov 2021 17:28:05 GMT, Joe Wang wrote:
>> Add setProperty/getProperty methods to the XPath API so that properties can
>> be supported in the future.
>
> Joe Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> adjust wording
On Fri, 5 Nov 2021 17:31:50 GMT, Naoto Sato wrote:
> Please review the subject fix. In light of JEP400, Java runtime can/should
> start in UTF-8 charset if the underlying native encoding is not supported.
This pull request has now been integrated.
Changeset: b8453ebd
Author: Naot
On Mon, 15 Nov 2021 22:43:37 GMT, Naoto Sato wrote:
> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
> PrintStream to its charset. This issue was raised during the conversations in
> https://github.com/openjdk/jdk/pull/5771
> A corresponding CSR h
On Tue, 16 Nov 2021 21:49:55 GMT, Naoto Sato wrote:
> BTW, I still observe on Windows (system locale=ja-JP):
>
> ```
> D:\projects\jdk\git\jdk>.\build\windows-x64\jdk\bin\jshell
> -J-Duser.language=ja
> | JShellへようこそ -- バージョン18-internal
> | 概要については、次を入力してください:
On Mon, 15 Nov 2021 17:28:30 GMT, Roger Riggs wrote:
> The ObjectInputStream.GetField.get(String name, Object val) method is
> returning null instead of throwing an exception when the class of the object
> is not found. The caller is not able to correctly handle the case where the
> class is
On Wed, 17 Nov 2021 13:02:10 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace jnuEncoding in jni_util.c with UTF-8, if platform encoding is not
>> supported
&
> Please review the subject fix. In light of JEP400, Java runtime can/should
> start in UTF-8 charset if the underlying native encoding is not supported.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Removed changes to Uti
201 - 300 of 1638 matches
Mail list logo
