On Tue, 16 Nov 2021 21:09:08 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 corresp
On Tue, 16 Nov 2021 20:10:53 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Made PrintStream::charset() public, charset field final, and refined
>> wordings.
>
&
wse/JDK-8277078
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Refined PrintStream::charset()'s method description, and moved it down along
with other instance methods.
-
Changes:
- all: https://git.openjdk.java.ne
wse/JDK-8277078
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Made PrintStream::charset() public, charset field final, and refined wordings.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6401/files
On Tue, 16 Nov 2021 05:25:33 GMT, Jaikiran Pai 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 has also been
On Tue, 16 Nov 2021 12:21:20 GMT, Alan Bateman 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 has also been
On Tue, 16 Nov 2021 10:37:12 GMT, Ichiroh Takiguchi
wrote:
> I tested some of java tool commands on #5771 .
>
> > jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe,
> > jpackage.exe
>
> It worked fine as expected on CentOS7 (ja_JP.eucjp locale) and Windows 10 Pro
>
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 has also been drafted:
https://bugs.openjdk.java.net/browse/JDK-8277078
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
On Mon, 15 Nov 2021 02:40:14 GMT, Ichiroh Takiguchi
wrote:
>> I reproduced those failures on Debian Linux. Corrected the issue by
>> replacing unsupported jnu encoding with `UTF-8` in `System::initPhase1`.
>
> @naotoj , sorry for bothering you again.
> Still I got exception. It seems value
> 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:
Replace jnuEn
On Sun, 14 Nov 2021 07:23:18 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed indentation
>
> src/java.base/share/classes/java/lang/System.java line 2123:
>
> 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:
Move UTF-8 fallb
> 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:
Fixed inden
On Sat, 13 Nov 2021 19:24:07 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Force the jnu encoding to UTF-8 if the original one is not supported
>
> src/jav
> 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:
Eliminated unnecessary
On Fri, 12 Nov 2021 19:11:07 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.
>
> Naoto Sato has updated the pull request incrementally with one ad
> 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:
Force the jnu encoding to
On Fri, 12 Nov 2021 12:25:20 GMT, Pavel Rappo wrote:
> Please review this simple two-hunk fix to the documentation comment of
> java.util.Properties#load(java.io.Reader). The first hunk (line/lines) is a
> suggestion. I believe it reads better since the plurality is more idiomatic;
> native
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
On Tue, 9 Nov 2021 22:29:12 GMT, Naoto Sato wrote:
> Simple doc clarification where the `toString()` output only conforms to ISO
> 8601 if the seconds in the offset are zero.
This pull request has now been integrated.
Changeset: bce35ac1
Author: Naoto Sato
URL:
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
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/Decimal
se verifying it). Corresponding CSR
> has also been drafted: https://bugs.openjdk.java.net/browse/JDK-8276249
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Using @code tag for `Set`.
-
Changes:
- all: https://git.openjdk.ja
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
> -
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 03:31:11 GMT, Ichiroh Takiguchi
wrote:
>>> There may be an argument that the JDK should emit a warning at startup.
>>
>> Updated to emit a warning, if `sun.jnu.encoding` is not supported.
>
> Hello @naotoj .
> I appreciate your code update.
> I'd like to confirm one thing.
On Tue, 9 Nov 2021 22:29:12 GMT, Naoto Sato wrote:
> Simple doc clarification where the `toString()` output only conforms to ISO
> 8601 if the seconds in the offset are zero.
Absolutely. Will file a CSR.
-
PR: https://git.openjdk.java.net/jdk/pull/6321
Simple doc clarification where the `toString()` output only conforms to ISO
8601 if the seconds in the offset are zero.
-
Commit messages:
- 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for
years <= 1893
Changes:
On Mon, 8 Nov 2021 09:44:34 GMT, Alan Bateman wrote:
> There may be an argument that the JDK should emit a warning at startup.
Updated to emit a warning, if `sun.jnu.encoding` is not supported.
-
PR: https://git.openjdk.java.net/jdk/pull/6282
> 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:
Emit a warning on unsup
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.
The same rationale as JEP 400, that UTF-8 is the de-facto encoding thes
On Sat, 6 Nov 2021 17:25:39 GMT, Alan Bateman wrote:
>> Thanks @AlanBateman .
>> In my understanding, sun.jnu.encoding property may be related file system
>> access.
>> Java may not be access to appropriate file.
>> I mean if the file name has malformed character, it may be changed to "?".
>>
On Fri, 5 Nov 2021 20:10:28 GMT, Joe Wang wrote:
> Do you need to add test?
I would if I could, but specifying the environment dependent settings in the
test would be fragile and error-prone, so I did not add a test but marked the
issue as `noreg-hard`.
-
PR:
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.
-
Commit messages:
- Use UTF-8 if jnuEncoding is not supported
- Utilized 2-arg Charset.forName()
- 8275007: Java fails to start
On Thu, 4 Nov 2021 16:52:48 GMT, Ludvig Janiuk wrote:
> The first table is missing row headers, adding them to aid screen readers.
LGTM.
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/6262
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).
On Wed, 3 Nov 2021 21:57:44 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
On Wed, 3 Nov 2021 19:44:35 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
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
On Wed, 3 Nov 2021 17:23:51 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
On Wed, 3 Nov 2021 17:23:51 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
On Wed, 3 Nov 2021 11:58:42 GMT, Pavel Rappo wrote:
> This PR fixes two sentences which conflate a string with its length, and also
> makes the "equivalency wording" consistent.
>
> There are many ways to fix "the resulting String may be a different length
> than the original String". The
On Mon, 1 Nov 2021 18:31:17 GMT, Naoto Sato wrote:
> This is a leftover document fix to `String` class for the JEP 400.
> Corresponding CSR has also been drafted:
> https://bugs.openjdk.java.net/browse/JDK-8276238
This pull request has now been integrated.
Changeset: 495c82
This is a leftover document fix to `String` class for the JEP 400.
Corresponding CSR has also been drafted:
https://bugs.openjdk.java.net/browse/JDK-8276238
-
Commit messages:
- 8276188: Clarify "default charset" descriptions in String class
Changes:
On Mon, 1 Nov 2021 15:04:16 GMT, Pavel Rappo wrote:
> Please review this PR. A comprehensive test job has been scheduled; I'll
> notify this thread once that job has completed.
Marked as reviewed by naoto (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6191
On Fri, 29 Oct 2021 15:35:50 GMT, Roger Riggs wrote:
>> The ObjectInputStream.GetField method `get(String name, Object val)` should
>> have been throwing
>> a ClassNotFoundException if the class was not found. Instead the
>> implementation was returning null.
>> A design error does not allow
On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote:
> Please review the integration of tzdata2021e (including tzdata2021d) to the
> JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests.
>
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java
On Thu, 28 Oct 2021 18:15:33 GMT, Brian Burkhalter wrote:
>> Please consider this proposed change to ignore comparing the total size of
>> `/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since
On Wed, 20 Oct 2021 17:23:36 GMT, Naoto Sato wrote:
> During the review of JEP 400, a proposal to provide an overloaded method to
> `Charset.forName()` was suggested
> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This
> PR is to implement the proposal. A
On Tue, 26 Oct 2021 19:00:44 GMT, Brian Burkhalter wrote:
> Please consider this proposed change to ignore comparing the total size of
> `/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
test/jdk/java/io/File/GetXSpace.java line 210:
> 208: if (Platform.isOSX() &&
On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote:
> Enhance ASCII-compatible `DoubleByte` encodings to make use of the
> `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such
> `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte
> encoders - and
On Tue, 26 Oct 2021 10:42:49 GMT, Daniel Fuchs wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflecting review comments
>
> src/java.base/share/classes/java/io/Console.java line
On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote:
> Trivial clean-up.
This pull request has now been integrated.
Changeset: 63e0f344
Author: Naoto Sato
URL:
https://git.openjdk.java.net/jdk/commit/63e0f344e9a2da135c76caff11e437dfc40408a6
Stats: 2 lines in 2 files changed
On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote:
> Trivial clean-up.
No, I did not check. I simply removed the `true &&` as it is logically correct.
There's a test specifying `IBM964` in `sun.nio.cs.TestIBMBugs.java`, but not
sure it tests both paths or not.
-
Trivial clean-up.
-
Commit messages:
- 8275767: JDK source code contains redundant boolean operations in
jdk.charsets
Changes: https://git.openjdk.java.net/jdk/pull/6110/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6110=00
Issue:
On Sat, 23 Oct 2021 19:29:30 GMT, Sergey Bylokhov wrote:
> Just an idea, should we check that the second parameter is null or not? Any
> pros and cons of that? For example should this code be allowed:
>
> ```
> var cs = Charset.forName(charsetName, null);
> if (cs == null) {
>
.net/browse/JDK-8275348
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Reflecting review comments
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6045/files
- new: https://git.openjdk.java.net/jdk/pull/6045
On Sat, 23 Oct 2021 06:42:52 GMT, Alan Bateman wrote:
> I think you'll need to adjust the description make it clear that "fallback"
> is used when the input is not a legal charset name or the charset is not
> available.
Made the method description clearer.
-
PR:
On Fri, 22 Oct 2021 04:54:35 GMT, Glavo wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Moved the null sentence into @param tag.
>
> Oh, I found that I checked the outdated sour
On Fri, 22 Oct 2021 02:07:44 GMT, Sergey Bylokhov wrote:
>> I first thought of swallowing all exceptions in 2-arg forName(), but decided
>> not to do that. Because `IllegalArgumentException` and
>> `IllegalCharsetNameException` are for the validity of the passed
>> `charsetName`, like
.net/browse/JDK-8275348
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Removed `@throws IllegalCharsetNameException`
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6045/files
- new: https://git.openjdk.java.ne
On Tue, 19 Oct 2021 04:08:12 GMT, Wu Yan wrote:
>> Hi,
>> Please help me review the change to enhance getting time zone ID from
>> /etc/localtime on linux.
>>
>> We use `realpath` instead of `readlink` to obtain the link name of
>> /etc/localtime, because `readlink` can only read the value
On Thu, 21 Oct 2021 16:06:31 GMT, Ichiroh Takiguchi
wrote:
> I'd like to write down following code without `try-catch`.
You don't *have to* try-catch those exceptions if you are not interested, as
they are subclasses of `RuntimeException`.
> ```
> var cs = Charset.forName(charsetName, null);
On Thu, 21 Oct 2021 09:33:30 GMT, Daniel Fuchs wrote:
>> Right, I think both try-catch usages will be removed.
>
> Apparently `IllegalCharsetNameException` or `IllegalArgumentException` could
> still be thrown - so removing the `try-catch` would be a change of behaviour
> in those cases. It
On Thu, 21 Oct 2021 15:00:03 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/java/io/Console.java line 594:
>>
>>> 592: cs = Charset.forName(StaticProperty.nativeEncoding(),
>>> Charset.defaultCharset());
>>> 593: } catch (Exception ignored) {
>>> 594:
On Wed, 20 Oct 2021 18:58:34 GMT, Alan Bateman wrote:
>> Thanks, Joe. Moved that explanation into the `fallback` param, which I
>> initially intended.
>
> The java.nio.charset package has the usual "Unless otherwise noted, passing a
> null argument ..." so if fallback is allowed to be null
On Wed, 20 Oct 2021 18:37:05 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Moved the null sentence into @param tag.
>
> src/java.base/share/classes/java/nio/charset/Ch
.net/browse/JDK-8275348
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Moved the null sentence into @param tag.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6045/files
- new: https://git.openjdk.java.ne
During the review of JEP 400, a proposal to provide an overloaded method to
`Charset.forName()` was suggested
[[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR
is to implement the proposal. A CSR is also drafted as
https://bugs.openjdk.java.net/browse/JDK-8275348
On Mon, 18 Oct 2021 20:49:07 GMT, Naoto Sato wrote:
> Removing a problem-listed test case, which has little value in itself.
> Confirmed it did succeed on all platforms before the removal.
This pull request has now been integrated.
Changeset: 8a3e0a1f
Author: Naoto Sato
URL:
On Wed, 6 Oct 2021 05:04:28 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
Removing a problem-listed test case, which has little value in itself.
Confirmed it did succeed on all platforms before the removal.
-
Commit messages:
- 7008363: TEST_BUG: test/java/lang/StringCoding/CheckEncodings.sh does
nothing and is very slow at that
Changes:
On Thu, 14 Oct 2021 15:50:28 GMT, Naoto Sato wrote:
> Fixing a regression in which `file.encoding` was initialized by
> `sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS
> platforms. tier1-3 tests passed on all platforms.
This pull request has now
On Mon, 4 Oct 2021 10:24:01 GMT, Jan Lahoda wrote:
>> Helllo @naotoj .
>> I used `System.console()` and `Console.charset()`.
>>
>> The following executables had same issue, I fixed them.
>>> jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe,
>>> jpackage.exe
>>
>> I
On Thu, 14 Oct 2021 15:50:28 GMT, Naoto Sato wrote:
> Fixing a regression in which `file.encoding` was initialized by
> `sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS
> platforms. tier1-3 tests passed on all platforms.
Filed a CSR: https://bugs.openjdk.
Fixing a regression in which `file.encoding` was initialized by
`sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS
platforms. tier1-3 tests passed on all platforms.
-
Commit messages:
- 8275145: file.encoding system property has an incorrect value on Windows
On Tue, 12 Oct 2021 21:10:12 GMT, Andrey Turbanov wrote:
> Remove 3 unused HashMap's.
> Reported here
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html
> I did the similar PR to treetenbp and it was merged
> https://github.com/ThreeTen/threetenbp/pull/155
On Wed, 13 Oct 2021 17:43:29 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review the fix to address a javadoc issue for the Deflater::deflate
> methods that were added as part of JDK-6341887 that could throw a
> ReadOnlyBufferException.
>
> The` @throws ` clause for
On Wed, 13 Oct 2021 09:15:25 GMT, Wu Yan wrote:
>> Hi,
>> Please help me review the change to enhance getting time zone ID from
>> /etc/localtime on linux.
>>
>> We use `realpath` instead of `readlink` to obtain the link name of
>> /etc/localtime, because `readlink` can only read the value
On Tue, 12 Oct 2021 20:39:13 GMT, Andrey Turbanov wrote:
>> StringBuffer is a legacy synchronized class. There are more modern
>> alternatives which perform better:
>> 1. Plain String concatenation should be preferred
>> 2. StringBuilder is a direct replacement to StringBuffer which generally
On Mon, 11 Oct 2021 21:05:46 GMT, Andrey Turbanov wrote:
>> src/java.base/share/classes/java/lang/Character.java line 123:
>>
>>> 121: * than U+ are called supplementary characters. The Java
>>> 122: * platform uses the UTF-16 representation in {@code char} arrays and
>>> 123: * in the
On Thu, 9 Sep 2021 08:25:44 GMT, Wu Yan wrote:
>> Hi,
>> Please help me review the change to enhance getting time zone ID from
>> /etc/localtime on linux.
>>
>> We use `realpath` instead of `readlink` to obtain the link name of
>> /etc/localtime, because `readlink` can only read the value of
On Wed, 6 Oct 2021 05:04:28 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
On Wed, 6 Oct 2021 18:08:04 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8274544: Langtools command's usage were garbled on Japanese Windows
>
> I got your iss
On Thu, 7 Oct 2021 21:30:22 GMT, Naoto Sato wrote:
> While working on tzdata2021c update, I noticed there is a dead code in
> `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for
> `endOfDay` for certain cases. These are no longer needed as JDK's code is
> alr
While working on tzdata2021c update, I noticed there is a dead code in
`sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for
`endOfDay` for certain cases. These are no longer needed as JDK's code is
already capable of dealing with transitions beyond the end of the day.
On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov
wrote:
> StringBuffer is a legacy synchronized class. There are more modern
> alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have
On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato wrote:
> This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c
> level. Note that the tz data is "as is", as released by IANA. No `merged
> links` are retracted.
> The PR also fixes two issues along
It was meant to be a vertical ellipsis. In hindsight, we could use the
explicit character for that purpose. ('⋮' U+22EE)
Naoto
On 10/6/21 12:07 PM, Andrey Turbanov wrote:
Hello.
While reading the javadoc of CollationElementIterator I found a
strange colon in the example.
On Wed, 6 Oct 2021 19:43:06 GMT, Sean Coffey wrote:
>> This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c
>> level. Note that the tz data is "as is", as released by IANA. No `merged
>> links` are retracted.
>> The PR also fixes two issues along with the 2021c upgrade.
>
On Wed, 6 Oct 2021 05:04:28 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
On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov
wrote:
> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't
> touch primitive types casts.
Calendar-related changes look good to me.
This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c
level. Note that the tz data is "as is", as released by IANA. No `merged links`
are retracted.
The PR also fixes two issues along with the 2021c upgrade.
-
Commit messages:
- Fix for Asia/Amman test case
On Mon, 4 Oct 2021 07:13:37 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
Hi John,
Please see the JEP 400, which changes the default charset to UTF-8
across platforms:
https://openjdk.java.net/jeps/400
HTH,
Naoto
On 10/4/21 8:47 AM, John Platts wrote:
Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as the
default codepage by setting an
On Mon, 4 Oct 2021 07:13:37 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
On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato wrote:
> This is to incorporate the ISO 4217 amendment #170, which has been released
> today, effective immediately.
This pull request has now been integrated.
Changeset: f2404d60
Author: Naoto Sato
URL:
https://git.openjdk.java.n
This is to incorporate the ISO 4217 amendment #170, which has been released
today, effective immediately.
-
Commit messages:
- 8274658: ISO 4217 Amendment #170 Update
Changes: https://git.openjdk.java.net/jdk/pull/5790/files
Webrev:
On Thu, 30 Sep 2021 09:36:34 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.
301 - 400 of 1638 matches
Mail list logo
