On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie wrote:
> I have failed to reproduce the working conditions that makes a file actually
> unreadable for the owner on Windows, neither on my GHA test repo, nor
> locally.
I had quick look at the CI setup we have access to. It appears that this
On Mon, 9 May 2022 18:59:43 GMT, Naoto Sato wrote:
> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support
> second-level resolution, enabling round trips with `java.time.ZoneOffset`s.
> Corresponding CSR is also being drafted.
src/java.base/share/classes/java/util/TimeZo
On Mon, 9 May 2022 18:59:43 GMT, Naoto Sato wrote:
> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support
> second-level resolution, enabling round trips with `java.time.ZoneOffset`s.
> Corresponding CSR is also being drafted.
src/java.base/share/classes/java/util/TimeZo
On Thu, 10 Mar 2022 18:34:27 GMT, Jim Laskey wrote:
>> Several attempts have been made to improve Formatter's numeric performance
>> by caching the current Locale zero. Such fixes, however, ignore the real
>> issue, which is the slowness of fetching DecimalFormatSymbols. By directly
>> caching
On Fri, 11 Mar 2022 10:16:33 GMT, Jim Laskey wrote:
>> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 192:
>>
>>> 190:
>>> 191: /**
>>> 192: * {@return locale used to create this instance}
>>
>> Hello Jim, the opening and closing `{`, I think aren't needed for a
On Thu, 10 Mar 2022 18:34:27 GMT, Jim Laskey wrote:
>> Several attempts have been made to improve Formatter's numeric performance
>> by caching the current Locale zero. Such fixes, however, ignore the real
>> issue, which is the slowness of fetching DecimalFormatSymbols. By directly
>> caching
On Mon, 7 Mar 2022 20:36:36 GMT, Jim Laskey wrote:
>> Several attempts have been made to improve Formatter's numeric performance
>> by caching the current Locale zero. Such fixes, however, ignore the real
>> issue, which is the slowness of fetching DecimalFormatSymbols. By directly
>> caching
On Sat, 5 Mar 2022 14:20:40 GMT, Jaikiran Pai wrote:
> will now try and update/use this cached class level static state DFS. That
> would thus require some kind of thread safety semantics to be implemented for
> this new getDecimalFormatSymbols(Locale) method, isn't it?
A bit mo
On Fri, 4 Mar 2022 21:17:50 GMT, Jim Laskey wrote:
>> Several attempts have been made to improve Formatter's numeric performance
>> by caching the current Locale zero. Such fixes, however, ignore the real
>> issue, which is the slowness of fetching DecimalFormatSymbols. By directly
>> caching
On Mon, 21 Feb 2022 12:42:37 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial change to the javadoc of
> `DateTimeFormatter.getDecimalStyle()` method which fixes the typo noted in
> https://bugs.openjdk.java.net/browse/JDK-8282190?
This pull request has now been i
On Mon, 21 Feb 2022 12:42:37 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial change to the javadoc of
> `DateTimeFormatter.getDecimalStyle()` method which fixes the typo noted in
> https://bugs.openjdk.java.net/browse/JDK-8282190?
Thank you everyone for th
Can I please get a review of this trivial change to the javadoc of
`DateTimeFormatter.getDecimalStyle()` method which fixes the typo noted in
https://bugs.openjdk.java.net/browse/JDK-8282190?
-
Commit messages:
- 8282190: Typo in javadoc of
java.time.format.DateTimeFormatter#getDe
On Fri, 24 Sep 2021 14:36:07 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>
> As noted in that issue, trying to class load
> `sun.util.calendar.Cale
On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which proposes to fix the issue
>> reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>>
>> As noted in that issue, trying to class load
>> `sun.uti
On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which proposes to fix the issue
>> reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>>
>> As noted in that issue, trying to class load
>> `sun.uti
On Fri, 24 Sep 2021 17:53:03 GMT, Naoto Sato wrote:
>> Jaikiran Pai has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Minor test adjustments as suggested by Naoto
>> - use a holder instead of volatile,
; additionally loads a few other classes concurrently. These classes have
> specific static initialization which leads the calls to
> `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`.
> Including these classes in the tests ensures that this deadlock hasn't
> "move
Can I please get a review for this change which proposes to fix the issue
reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem`
and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to
On Fri, 16 Apr 2021 04:06:54 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this proposed fix for
>> https://bugs.openjdk.java.net/browse/JDK-8262108?
>>
>> As noted in a comment in that issue, the bug relates to the return value of
>> `Cal
On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai wrote:
> Can I please get a review for this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8262108?
>
> As noted in a comment in that issue, the bug relates to the return value of
> `Calendar.getDisplayNames` for the
and is probably what hid this
> issue in the first place? To fix this, I have added an additional commit
> which updates this test case to properly test the `AM_PM` field values.
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
On Fri, 16 Apr 2021 03:51:22 GMT, Naoto Sato wrote:
>> Hello Naoto,
>>
>> As far as I can see, the testMap cannot be used to test the day period
>> strings. More specifically, consider this change (git diff) that I did as
>> you suggested (unless I misunderstood what you meant):
>>
>>
>> +
On Thu, 15 Apr 2021 03:57:18 GMT, Naoto Sato wrote:
>> Jaikiran Pai has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - update existing testcase based on review comment
>> - Improve code comment to be
and is probably what hid this
> issue in the first place? To fix this, I have added an additional commit
> which updates this test case to properly test the `AM_PM` field values.
Jaikiran Pai has updated the pull request incrementally with three additional
commits since the last revision:
On Wed, 14 Apr 2021 18:01:10 GMT, Naoto Sato wrote:
>> Jaikiran Pai has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update existing NarrowNamesTest to match expectations
>> - Naoto's review suggest
On Wed, 14 Apr 2021 17:14:55 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this proposed fix for
>> https://bugs.openjdk.java.net/browse/JDK-8262108?
>>
>> As noted in a comment in that issue, the bug relates to the return value of
>> `Cal
and is probably what hid this
> issue in the first place? To fix this, I have added an additional commit
> which updates this test case to properly test the `AM_PM` field values.
Jaikiran Pai has updated the pull request incrementally with two additional
commits since the last revisi
On Tue, 13 Apr 2021 17:56:12 GMT, Naoto Sato wrote:
>Have you run regression tests in java.time? If I am not mistaken, your changes
>simply seem to nullify the day period support.
Hello @naotoj, my tier1 test run passed without issues locally with this change:
==
T
and is probably what hid this
> issue in the first place? To fix this, I have added an additional commit
> which updates this test case to properly test the `AM_PM` field values.
Jaikiran Pai has updated the pull request incrementally with two additional
commits since the last revision:
On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai wrote:
> Can I please get a review for this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8262108?
>
> As noted in a comment in that issue, the bug relates to the return value of
> `Calendar.getDisplayNames` for the
Can I please get a review for this proposed fix for
https://bugs.openjdk.java.net/browse/JDK-8262108?
As noted in a comment in that issue, the bug relates to the return value of
`Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation
has started returning invalid values fo
On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai wrote:
> Can I please get a review for this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8262108?
>
> As noted in a comment in that issue, the bug relates to the return value of
> `Calendar.getDisplayNames` for the
32 matches
Mail list logo
