This changes the specification of `DateTimeFormatterBuilder.appendFraction` to
more clearly specify that the formatter will throw an exception if you attempt
to print a value outside of the value range of the given field. Changes
suggested by @jodastephen in #6188.
-
Commit message
On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad wrote:
> This changes the specification of `DateTimeFormatterBuilder.appendFraction`
> to more clearly specify that the formatter will throw an exception if you
> attempt to print a value outside of the value range of the given field.
> Changes
On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad wrote:
> This changes the specification of `DateTimeFormatterBuilder.appendFraction`
> to more clearly specify that the formatter will throw an exception if you
> attempt to print a value outside of the value range of the given field.
> Changes
On Wed, 3 Nov 2021 07:05:08 GMT, Yoshiki Sato wrote:
> Please review this PR to update the TimeZoneNames files. @naotoj @coffeys
>
> Some short name changes are not integrated to the JDK. It was detected by the
> change made in JDK-8275766.
> - Africa/Juba change was done by 2017c
> - Afric
On Thu, 4 Nov 2021 16:07:01 GMT, Naoto Sato wrote:
> This fix is to require to include `Locale.ROOT` in the returned arrays/set
> from `getAvailableLocales()` methods in various locale-sensitive classes. The
> implementation has been including `Locale.ROOT` since its inception, it is
> simply
> This fix is to require to include `Locale.ROOT` in the returned arrays/set
> from `getAvailableLocales()` methods in various locale-sensitive classes. The
> implementation has been including `Locale.ROOT` since its inception, it is
> simply a doc clarification (+ a test case verifying it). Cor
On Wed, 10 Nov 2021 18:29:06 GMT, Pavel Rappo wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Using @code tag for `Set`.
>
> src/java.base/share/classes/java/time/format/DecimalStyle.java line 118:
>
>> 116: *
On Wed, 10 Nov 2021 19:05:17 GMT, Naoto Sato wrote:
>> This fix is to require to include `Locale.ROOT` in the returned arrays/set
>> from `getAvailableLocales()` methods in various locale-sensitive classes.
>> The implementation has been including `Locale.ROOT` since its inception, it
>> is si
On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
On Wed, 10 Nov 2021 19:16:58 GMT, Jonathan Gibbons wrote:
> Generally, the issue is related to the fact that we wrap a PrintStream in a
> PrintWriter ... and, if I understand correctly, the writer ends up with the
> wrong character encoding. Is it possible to change PrintWriter and/or
> PrintS
On Wed, 10 Nov 2021 19:05:17 GMT, Naoto Sato wrote:
>> This fix is to require to include `Locale.ROOT` in the returned arrays/set
>> from `getAvailableLocales()` methods in various locale-sensitive classes.
>> The implementation has been including `Locale.ROOT` since its inception, it
>> is si
On Wed, 10 Nov 2021 19:41:29 GMT, Jonathan Gibbons wrote:
> 1. `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)`
> should be redefined so that they internally check if the stream arg is a
> PrintStream, in which case they use the encoding from the `PrinStream`
> instead of
On Thu, 4 Nov 2021 16:07:01 GMT, Naoto Sato wrote:
> This fix is to require to include `Locale.ROOT` in the returned arrays/set
> from `getAvailableLocales()` methods in various locale-sensitive classes. The
> implementation has been including `Locale.ROOT` since its inception, it is
> simply
On Wed, 3 Nov 2021 07:05:08 GMT, Yoshiki Sato wrote:
> Please review this PR to update the TimeZoneNames files. @naotoj @coffeys
>
> Some short name changes are not integrated to the JDK. It was detected by the
> change made in JDK-8275766.
> - Africa/Juba change was done by 2017c
> - Afric
On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
On Wed, 10 Nov 2021 20:00:39 GMT, Alan Bateman wrote:
> > 1. `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)`
> > should be redefined so that they internally check if the stream arg is a
> > PrintStream, in which case they use the encoding from the `PrinStream`
> > instead
On Wed, 10 Nov 2021 19:46:09 GMT, Alan Bateman wrote:
> If there is resistance to fixing the tools then we might have to re-visit
> this.
It's not just the JDK tools that are an issue. I think that wrapping some
PrintStream into a PrintWriter is a common enough idiom that it is not
reasonabl
On Wed, 3 Nov 2021 07:05:08 GMT, Yoshiki Sato wrote:
> Please review this PR to update the TimeZoneNames files. @naotoj @coffeys
>
> Some short name changes are not integrated to the JDK. It was detected by the
> change made in JDK-8275766.
> - Africa/Juba change was done by 2017c
> - Afric
19 matches
Mail list logo
