On Sun, 24 Apr 2022 09:18:54 GMT, Ichiroh Takiguchi
wrote:
> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder
On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has n
On Tue, 26 Apr 2022 21:17:34 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has
> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.
Ichiroh Takiguchi has updated t
On Fri, 13 May 2022 18:29:56 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> h
On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has n
> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.
Ichiroh Takiguchi has updated t
> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.
Ichiroh Takiguchi has updated t
On Sat, 7 May 2022 06:50:40 GMT, Ichiroh Takiguchi
wrote:
>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has
>> Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Argument
On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has n
On Fri, 6 May 2022 15:13:38 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has no
> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.
Ichiroh Takiguchi has updated t
On Thu, 5 May 2022 01:34:48 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has no
On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has n
> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.
Ichiroh Takiguchi has updated t
On Thu, 5 May 2022 01:31:24 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> h
On Tue, 26 Apr 2022 21:17:34 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has
> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.
Ichiroh Takiguchi has updated t
On Tue, 3 May 2022 18:35:33 GMT, Naoto Sato wrote:
>> I think 3 processes required for this testing.
>> 1. Start test process on ja_JP.eucjp locale
>> 2. Set the test data by encoder
>> 3. Verify the encoded data by decoder
>>
>> To verify the encoded data, I think I need to check the byte
On Mon, 2 May 2022 20:50:11 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has no
On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has n
> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.
Ichiroh Takiguchi has updated t
On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has n
On Wed, 27 Apr 2022 17:20:11 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> h
On Tue, 26 Apr 2022 21:17:34 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has
> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.
Ichiroh Takiguchi has updated t
On JDK19 with Linux ja_JP.eucjp locale,
System.getenv() returns unexpected value if environment variable has Japanese
EUC characters.
It seems this issue happens because of JEP 400.
Arguments for ProcessBuilder have same kind of issue.
-
Commit messages:
- 8285517: System.getenv()
On Tue, 22 Feb 2022 12:17:59 GMT, Ichiroh Takiguchi
wrote:
> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX.
> The test was failed by:
> Incorrect handling of envstrings containing NULs
>
> According to my investigation, this issue was happened after following change
On Fri, 25 Feb 2022 15:03:19 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add null check
>
> My preference is to pass the unmodified LIBPATH in the envir
"sleep" in Basic.java
>
> test.nativepath value was added into AIX's LIBPATH during running this
> testcase.
> On AIX, test.nativepath value should be removed from LIBPATH value before
> comparing the values.
Ichiroh Takiguchi has updated the pull request incrementally with
On Thu, 24 Feb 2022 18:51:08 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add null check
>
> The piece I was missing is that the HotSpot AIX specific code
On Thu, 24 Feb 2022 18:51:08 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add null check
>
> The piece I was missing is that the HotSpot AIX specific code
On Thu, 24 Feb 2022 17:01:13 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add null check
>
> Javac is compiling the source to a .class file. The contents of
On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi
wrote:
>> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX.
>> The test was failed by:
>> Incorrect handling of envstrings containing NULs
>>
>> According to my investigation, this issue was happe
On Wed, 23 Feb 2022 19:59:46 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add null check
>
> The changes seem ok, modifying both the LIBPATH passed in the e
On Wed, 23 Feb 2022 15:44:07 GMT, Tyler Steele wrote:
>> @RogerRiggs
>> Many thanks. that's good point.
>> Only 1st part has `test.nativepath` because of following code.
>>
>> if (AIX.is()) {
>> pb.environment().put("LIBPATH", libpath);
>> }
>>
>> On current condition, parent (main)
"sleep" in Basic.java
>
> test.nativepath value was added into AIX's LIBPATH during running this
> testcase.
> On AIX, test.nativepath value should be removed from LIBPATH value before
> comparing the values.
Ichiroh Takiguchi has updated the pull request incrementally with
On Tue, 22 Feb 2022 18:10:28 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use expectedLibpath
>
> For my curiosity, how is AIX different from other Linux
"sleep" in Basic.java
>
> test.nativepath value was added into AIX's LIBPATH during running this
> testcase.
> On AIX, test.nativepath value should be removed from LIBPATH value before
> comparing the values.
Ichiroh Takiguchi has updated the pull request incrementally with
On Tue, 22 Feb 2022 17:20:25 GMT, Ichiroh Takiguchi
wrote:
>> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX.
>> The test was failed by:
>> Incorrect handling of envstrings containing NULs
>>
>> According to my investigation, this issue was happe
"sleep" in Basic.java
>
> test.nativepath value was added into AIX's LIBPATH during running this
> testcase.
> On AIX, test.nativepath value should be removed from LIBPATH value before
> comparing the values.
Ichiroh Takiguchi has updated the pull request incrementally with
Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX.
The test was failed by:
Incorrect handling of envstrings containing NULs
According to my investigation, this issue was happened after following change
was applied.
JDK-8272600: (test) Use native "sleep" in Basic.java
test.nativepath
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
On Fri, 19 Nov 2021 16:48:03 GMT, Naoto Sato wrote:
>> Hello @naotoj .
>> For PrintStream.getCharset(), following changes may be required.
>>
>> +++ src/java.base/share/classes/java/io/OutputStreamWriter.java
>> +Charset getCharset() {
>> +return se.getCharset();
>> +}
>>
>>
On Thu, 18 Nov 2021 00:11:49 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
> > | 概要については、次を入力してください: /help intro
> >
> >
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 has also been
On Mon, 15 Nov 2021 17:28:44 GMT, Naoto Sato wrote:
>> @naotoj , sorry for bothering you again.
>> Still I got exception. It seems value "jnuEncoding" should be overwritten or
>> set "fastEncoding" to "FAST_UTF_8" on jnu_util.c.
>> Could you check this part again ?
>>
>> $ env
On Fri, 12 Nov 2021 19:11:16 GMT, Naoto Sato 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
>
> I reproduced those failures on Debian Linux.
On Wed, 10 Nov 2021 21:19:30 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - 8274544: Langtools command's usage were garbled on Japane
On Tue, 9 Nov 2021 19:38:01 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 additional
> commit
On Tue, 9 Nov 2021 19:38:01 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 additional
> commit
On Tue, 9 Nov 2021 19:38:01 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 additional
> commit
On Tue, 9 Nov 2021 19:38:46 GMT, Naoto Sato wrote:
>>> If this issue is not a part of JEP-400, I think UTF_8 may not be only
>>> solution for sun/nio/fs/Util.java.
>>> Please explain why UTF_8 is better than ISO_8859_1.
>>
>> Just to add to Naoto's comment. When the JDK starts in
On Tue, 19 Oct 2021 01:26:35 GMT, Jonathan Gibbons wrote:
>> Ichiroh Takiguchi has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR.
>
>
On Mon, 8 Nov 2021 09:44:34 GMT, Alan Bateman wrote:
>> If this issue is not a part of JEP-400, I think UTF_8 may not be only
>> solution for sun/nio/fs/Util.java.
>> Please explain why UTF_8 is better than ISO_8859_1.
>
>> If this issue is not a part of JEP-400, I think UTF_8 may not be only
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.
If this issue is not a part of JEP-400, I think UTF_8 may not be only solution
for
On Sat, 6 Nov 2021 16:20:41 GMT, Alan Bateman wrote:
>> @naotoj
>> I'm not reviewer.
>> Could you explain more detail, why JEP-400 needs to touch sun.jnu.encoding
>> system property's fallback ?
>
>> Could you explain more detail, why JEP-400 needs to touch sun.jnu.encoding
>> system
On Fri, 5 Nov 2021 20:22:03 GMT, Naoto Sato wrote:
>> Do you need to add test?
>
>> 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
On Wed, 3 Nov 2021 18:41:19 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - 8274544: Langtools command's usage were garbled on Japane
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
> 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.
Ichiroh Takiguchi has updated the pull reques
On Mon, 25 Oct 2021 14:20:52 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 ins
> 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.
Ichiroh Takiguchi has updated the pull reques
On Fri, 22 Oct 2021 17:33:43 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 CSR is
On Thu, 21 Oct 2021 18:00:46 GMT, Naoto Sato wrote:
>> I'm not reviewer.
>>
>> I'd like to write down following code without `try-catch`.
>>
>> var cs = Charset.forName(charsetName, null);
>> if (cs == null) cs = StandardCharsets.UTF_8;
>>
>> or please find out more easy way.
>
>> I'd like to
On Tue, 19 Oct 2021 01:26:35 GMT, Jonathan Gibbons 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
>
On Wed, 20 Oct 2021 19:02:30 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 CSR is
On Thu, 14 Oct 2021 23:43:47 GMT, Naoto Sato wrote:
>> @takiguc - if JShell is still an issue, is there a chance you could try this:
>> https://github.com/lahodaj/jdk/commit/cfa6b3eebbc22c5a48d31cfd692ff98690653686
>>
>> Not sure if it will help, but it might (this won't change the default
>>
On Fri, 8 Oct 2021 21:07:32 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
>
> BTW, does th
l used [5].
Questions:
I’d like to confirm
* This change was intentional or not ?
* We can revert tp JDK11’s spec ?
Thanks,
Ichiroh Takiguchi
[1] https://bugs.openjdk.java.net/browse/JDK-4947890
[2] http://hg.openjdk.java.net/jdk/jdk/rev/0bdbf854472f#l12.466
[3] http://hg.openjdk.java.net/jdk/j
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 Wed, 6 Oct 2021 00:02:55 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 just grep
On Mon, 4 Oct 2021 16:24:18 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
>
> src/jdk.compil
> 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.
Ichiroh Takiguchi has updated the pull request i
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 Fri, 1 Oct 2021 18:14:11 GMT, Naoto Sato 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.
>
>
> 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.
Ichiroh Takiguchi has updated the pull request i
On Fri, 1 Oct 2021 12:13:03 GMT, Pavel Rappo 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 Thu, 30 Sep 2021 21:45:15 GMT, Naoto Sato wrote:
>> Screenshot
>> 
>>
>> javac does not use PrintStream for standard out/err, it uses PrintWriter.
>> I put some codes on
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
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.
-
Commit messages:
- Langtools command's usage were
On Fri, 30 Apr 2021 16:11:30 GMT, Ichiroh Takiguchi
wrote:
>> When an invalid character is converted by getBytes() method, the character
>> is converted to replacement byte data.
>> Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset.
>> EB
ching character set.
> On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F",
> but "\x0E\x40\x40\x6F\x0F"
> SI is not in right place.
>
> Also ISO2022 related charsets use escape sequence to switch character set.
> But same
On Mon, 12 Apr 2021 23:01:24 GMT, Naoto Sato wrote:
>> Please review the changes for the subject issue. This has been suggested in
>> a recent discussion thread for the JEP 400
>> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>> A CSR has also been
/~itakiguchi/8242541/webrev.01/
Thanks,
Ichiroh Takiguchi
On 2020-04-23 00:54, naoto.s...@oracle.com wrote:
Hi Takiguchi-san,
Change looks good. I'd expect a test case in
open/test/jdk/java/nio/charset/Charset/RegisteredCharsets.java for the
added "ISO8859_16" alias.
Naoto
On 4/20/
charset source codes should be template style
I appreciate your feedback and suggestions.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
Hello Naoto.
I tested webrev.06 code.
It's fine, thanks.
I'm interested in about @module for these testcases.
I think webrev.04 code worked via jtreg.
I could not see any warning.
At this case, @module is required ?
Thanks,
Ichiroh Takiguchi
On 2020-03-24 10:06, naoto.s...@oracle.com wrote
be handled as error.
What do you think ?
Thanks,
Ichiroh Takiguchi
On 2020-03-21 01:21, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8241311
The proposed changeset is located at:
https://cr.openjdk.java.net/~naoto/8241311
Hello Naoto.
I appreciate your comments.
I modified TestMS950.java testcase.
I think it's easy to read.
Could you review the fix again ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8232161
Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.03/
Thanks,
Ichiroh Takiguchi
Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.02/
Thanks,
Ichiroh Takiguchi
On 2020-03-03 10:31, naoto.s...@oracle.com wrote:
Hi Takiguchi-san,
A few comments:
- I'd recommend sorting the entries in MS950.nr and test data in
TestMS950.java for readability.
- Add some comment
Hello.
Could you review the fix ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8232161
Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.01/
CSR 8233385 [1] was approved.
[1] https://bugs.openjdk.java.net/browse/JDK-8233385
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
Hello Naoto.
I appreciate your comments.
And sorry for my easy mistake.
Could you review the fix again ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8239965
Change: https://cr.openjdk.java.net/~itakiguchi/8239965/webrev.01/
Thanks,
Ichiroh Takiguchi
On 2020-02-27 05:56, naoto.s
] https://bugs.openjdk.java.net/browse/JDK-8235834
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
Hello Naoto.
Yes, I agree with your suggestion.
I'm very happy if you are the sponsor of this issue.
Thanks,
Ichiroh Takiguchi
On 2020-02-22 01:53, naoto.s...@oracle.com wrote:
Two subtle comments to the new webrev:
- I'd add "private" to those static finals.
- "cs.name()&qu
Hello Naoto.
I appreciate your suggestions.
I applied your suggestions into new patch.
Could you review the fix again ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8235834
Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.01/
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 2020
MAP14A B2C definition.
So I'd like to apply 34B003AF.RPMAP130 definition.
Thanks,
Ichiroh Takiguchi
On 2020-02-19 07:33, naoto.s...@oracle.com wrote:
Hi Takiguchi-san,
Can you please elaborate the rationale for the change? It looks like
IBM943 chaset hasn't changed for a long time, at least from
compatible entries compared
to MS932 charset.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
Hello.
This is reminder, again.
Could you review CSR JDK-8233385 [1] ?
[1] https://bugs.openjdk.java.net/browse/JDK-8233385
Thanks,
Ichiroh Takiguchi
On 2020-01-22 02:47, naoto.s...@oracle.com wrote:
Looks good to me.
Naoto
On 1/20/20 4:30 AM, Ichiroh Takiguchi wrote:
Hello.
This is just
Hello.
I have 2 concerns about CLDR Timezone translated data.
The detail information is in JDK-8236548 [1].
Can you show me how to solve this kind of ICU related issue ?
[1] https://bugs.openjdk.java.net/browse/JDK-8236548
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
Hello.
This is just a gentle reminder.
Could you review CSR JDK-8233385 [1] ?
[1] https://bugs.openjdk.java.net/browse/JDK-8233385
Thanks,
Ichiroh Takiguchi
On 2020-01-10 22:13, Ichiroh Takiguchi wrote:
Hello.
Could you review CSR JDK-8233385 [1] ?
[1] https://bugs.openjdk.java.net/browse
1 - 100 of 153 matches
Mail list logo
