On Mon, 29 Nov 2021 17:29:03 GMT, Naoto Sato wrote:
>> As I explained before, output file encoding which is created by `-Xstdout`
>> option is changed to native encoding instead of UTF-8 by
>> `-J-Dfile.encoding=COMPAT`.
>> In case of Linux ja_JP.eucjp locale, your explanation may be acceptable
On Fri, 19 Nov 2021 07:00:44 GMT, Ichiroh Takiguchi
wrote:
> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".
This pull request has been closed witho
On Mon, 22 Nov 2021 16:08:58 GMT, Ichiroh Takiguchi
wrote:
> JEP-400 was implemented by JDK18-b13.
> After JDK18-b13, garbled character was displayed by following code on
> Japanese Windows' command prompt.
>
> System.out.println("\u3042")
>
> Japanese &
On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi
wrote:
>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the p
On Wed, 24 Nov 2021 18:35:45 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8277398: javac does not accept encoding name COMPAT
>
> Sorry, but I am kind of lo
On Wed, 24 Nov 2021 08:47:54 GMT, Alan Bateman wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8277398: javac does not accept encoding name COMPAT
>
> I see this PR has been re
> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".
Ichiroh Takiguchi has updated the pull request incrementally with one
additional commit since the last revision:
k/jdk/pull/5771
> This issue also happens on Linux ja_JP.eucjp locale.
> RemoteExecutionControl.java change is required for this issue.
>
> Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal.
> AbstractTerminal.java change is required for this issue.
Ichiroh Takiguchi has update
On Mon, 22 Nov 2021 16:08:58 GMT, Ichiroh Takiguchi
wrote:
> JEP-400 was implemented by JDK18-b13.
> After JDK18-b13, garbled character was displayed by following code on
> Japanese Windows' command prompt.
>
> System.out.println("\u3042")
>
> Japanese &
On Fri, 19 Nov 2021 07:00:44 GMT, Ichiroh Takiguchi
wrote:
> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".
Thanks @AlanBateman and @naotoj .
I appreciate your g
JEP-400 was implemented by JDK18-b13.
After JDK18-b13, garbled character was displayed by following code on Japanese
Windows' command prompt.
System.out.println("\u3042")
Japanese "A" should be display ed, but garbled character was displayed.
Also saved jshell command list did not work as expect
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, 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
ncoding name COMPAT was defined for operating system encoding by JEP-400.
https://openjdk.java.net/jeps/400
But java does not accept "-encoding COMPAT".
-
Commit messages:
- 8277398: javac does not accept encoding name COMPAT
Changes: https://git.openjdk.java.net/jdk/pull/6475/files
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 J
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.
>
> Thi
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 J
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 stan
> 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 r
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 r
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 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
>> c
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, do
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 you
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
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.c
> 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 requ
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 co
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.
>
> The
> 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 requ
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.
>
> Fo
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 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.
>> EBCDI
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
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.
EBCDIC Mix charset encoder is stateful encoder.
Shift code should be added by switching character set.
On x-
On Thu, 21 Jan 2021 21:41:09 GMT, Dmitry Markov wrote:
>> Marked as reviewed by aivanov (Reviewer).
>
>> Hi,
>>
>> AWT's `TextComponent` is a `peered` input client, and Swing's
>> `JTextComponent` is an `active` input client. Thus it is OK to behave
>> differently. I would expect that AWT's on
On Wed, 20 Jan 2021 05:43:51 GMT, Sergey Bylokhov wrote:
> How do the native components work in that case like awt textarea or external
> apps like notepad?
I tested TextField+TextField, TextArea+TextArea, TextArea+TextField.
Without fix: Preedit string was cancel by input focus change.
With fi
On Tue, 19 Jan 2021 16:31:58 GMT, Ichiroh Takiguchi
wrote:
>>> > Fix:
>>> > It is necessary to take care of unconfirmed composition string once the
>>> > IME is going to be disabled.
>>>
>>> The fix commits the unconfirmed composition st
On Tue, 19 Jan 2021 13:18:22 GMT, Dmitry Markov wrote:
>>> Fix:
>>> It is necessary to take care of unconfirmed composition string once the IME
>>> is going to be disabled.
>>
>> The fix commits the unconfirmed composition string. Committing is better
>> than discarding. Is it possible to pres
Hello Dmitry.
The bugid seems to be private, so I don't know the details.
I think the current code can change the candidate string after getting
the focus.
If possible, could you show me the test instructions ?
Thanks,
Ichiroh Takiguchi
On 2021-01-19 20:16, Dmitry Markov wrote:
Pr
a.net/~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
charset source codes should be template style
I appreciate your feedback and suggestions.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
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 Takiguch
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 co
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
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
ply 03AF34B0.TPMAP14A 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
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
Hello.
Could you review CSR JDK-8233385 [1] ?
[1] https://bugs.openjdk.java.net/browse/JDK-8233385
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
ent between
Windows and Java.
Thanks,
Ichiroh Takiguchi
On 2019-10-31 01:25, naoto.s...@oracle.com wrote:
Takiguchi-san,
Personally I am reluctant to make this change. If we were to introduce
this, it will be a different encoding from the existing MS950, so
either 1) we need a new encoding, or
...
(Select "Create CSR" from "More" menu)
It worked ?
[1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs
Thanks,
Ichiroh Takiguchi
On 2019-10-29 03:03, naoto.s...@oracle.com wrote:
Hi Takiguchi-san,
On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:
Hello.
I have no idea
t was used as valuable data until now.
I think it's necessary to evaluate compatibility.
To Sato-san,
if you have any question and suggestion, please let me know.
To other reviewers,
please let me know if you have any question and concern.
Thanks,
Ichiroh Takiguchi
On 2019-10-19 16:36, Al
] https://bugs.openjdk.java.net/browse/JDK-8232161
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
ttps://bugs.openjdk.java.net/browse/JDK-8227919
Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.01/
It changes:
* 0xL is changed to 0xUL
* defined(__linux__) is added into defined(_LP64) line
Thanks,
--
Ichiro Takiguchi
IBM Japan Ltd.
"awt-dev" wrote on 2019/
long instead of unsigned int on
64bit Big endian.
It's same as Java8.
I think Solaris SPARC's issue can be fixed by this fix.
Vladimir,
I appreciate your great help.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 2019-07-23 20:00, Vladimir Kempik wrote:
Hello
it still crashes with "
[2] https://fedoraproject.org/wiki/I18N/InputMethods
Thanks,
Ichiroh Takiguchi
On 2019-07-22 23:58, Vladimir Kempik wrote:
Hello
I’m getting Bus Error on startup with
XMODIFIERS=@im=local ./xim_root
nothing yet in log at that moment.
Thanks, Vladimir
22 июля 2019 г., в 15:12, Ichiroh T
d current code did not work on even if Linux s390x
platform.
Thanks,
Ichiroh Takiguchi
On 2019-07-19 23:29, Vladimir Kempik wrote:
Hello
I’m probably missing something about XIM on X side here, using ssh
-X from ubuntu(with Xserver) to solaris11 sparc64 machine
the output is
fevent = 0x3
output into JDK-8227919 [1] or post it into mailing list.
I really appreciate if you are using XIM like IIIMF.
[1] https://bugs.openjdk.java.net/browse/JDK-8227919
[2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c
Thanks,
Ichiroh Takiguchi
Hello.
I built the new fixed code by GCC 8.2.1.
It worked fine.
Thanks,
Ichiroh Takiguchi
On 2019-04-26 23:04, Ichiroh Takiguchi wrote:
Hello Sergey.
See "Preedit State Callbacks" section on Xlib manual [1]
Return code for PreeditStartCallback should be int instead of
PreeditStartCallback,
+(XIMProc)(void *)&PreeditStartCallback,
[1]
https://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.html
Thanks,
Ichiroh Takiguchi
On 2019-04-26 08:14, Sergey Bylokhov wrote:
Hi, Ichiroh.
I got this build error when I tried to test this patch:
open/src/
es(pX11IMData->current_ic,
XNPreeditAttributes, pr_atrb, NULL);
2190 XFree((void *)pr_atrb);
2191 AWT_UNLOCK();
Thanks,
Ichiroh Takiguchi
On 2019-04-11 11:19, Sergey Bylokhov wrote:
Hi, Ichiroh.
Why the fix uses the "defined(MACOSX)" in a few places? I assume this
code is nev
Hello.
Could you review the fix and give me your suggestion, please ?
I really appreciate your feedback.
Currently, UnsupportedOperationException happens because of invalid
usage
by input method operation.
And I'd like to obtain a sponsor for this issue.
Thanks,
Ichiroh Takiguchi
On
Hello.
Could you review the fix and give me your suggestion, please ?
Thanks,
Ichiroh Takiguchi
On 2019-02-26 22:08, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8213232
Change: https://cr.openjdk.java.net/~itakiguchi/8213232
s/libX11/libX11.html
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 2018-12-04 11:22, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8213232
Change: https://cr.openjdk.java.net/~itakiguchi/8213232/webrev.00/
This issue is relat
Hello.
Could you review the fix and give me your suggestion, please ?
JDK-8212678 [1] has screen shots and movies.
Please check them also.
[1] https://bugs.openjdk.java.net/browse/JDK-8212678
Thanks,
Ichiroh Takiguchi
On 2019-01-23 21:18, Ichiroh Takiguchi wrote:
Hello.
Could you review the
Hello.
Could you review the fix and give me your suggestion ?
Thanks,
Ichiroh Takiguchi
On 2019-01-16 20:13, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8212678
Change: https://cr.openjdk.java.net/~itakiguchi/8212678/webrev.01
Hello Sergey.
Sorry, code conflict was there.
I fixed code conflict and modified Copyright year.
Could you review the fix again ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8212677
Change: https://cr.openjdk.java.net/~itakiguchi/8212677/webrev.01/
Thanks,
Ichiroh Takiguchi
IBM Japan
check them.
I'd like to obtain a sponsor for this issue.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 2018-11-18 22:22, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8212678
Change: http://cr.openjdk.java.net/~aleonard/winime/webr
Hello again.
Could you give me review comment and/or suggestion ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8212676
Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/
Thanks,
Ichiroh Takiguchi
On 2018-11-26 21:27, Ichiroh Takiguchi wrote:
Hello.
Could you review the
exception happened
with Xlib bundled input method.
Test instructions is in JDK-8213232.
I'd like to obtain a sponsor for this issue.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 2018-06-19 02:15, Ichiroh Takiguchi wrote:
Hello,
IBM would like to contribute Unix/X11 setCompositionEnableNative
Hello.
Could you review the fix ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8212677
Change: https://cr.openjdk.java.net/~itakiguchi/8212677/webrev.00/
Screen shots are in JDK-8212677.
I'd like to obtain a sponsor for this issue.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 2018-
to avoid unexpected working behavior on AIX
platform.
I'd like to obtain a sponsor for this issue.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 2018-06-18 18:57, Ichiroh Takiguchi wrote:
Hello.
This fix is really required for AIX's GUI.
System color setting and window manager
hiroh Takiguchi
IBM Japan, Ltd.
On 2018-06-15 02:26, Phil Race wrote:
This should go to i18n-dev as well.
-phil.
On 06/14/2018 10:14 AM, Ichiroh Takiguchi wrote:
Hello,
IBM would like to contribute Windows IME related Java Input Method
Framework patch to OpenJDK project.
Issue:
This patch ca
I'm very sorry for your confusion, please ignore previous mail.
I posted it on wrong mailing list.
Ichiroh Takiguchi
On 2018-11-15 03:11, Ichiroh Takiguchi wrote:
Hello.
Martin Buchholz suggested me via bugs.openjdk.java.net,
I should not touch non AIX side.
So I rewrote another code.
want to touch non AIX side code, but I need to rename 3 files
to avoid compilation issue.
IBM33722.java -> IBM33722.java.template
IBM964.java -> IBM964.java.template
SimpleEUCEncoder.java -> SimpleEUCEncoder.java.template
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
Or
Hello.
Could you review memory leak fix ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8211393
Change: https://cr.openjdk.java.net/~itakiguchi/8211393/webrev.00/
I'd like to obtain a sponsor for this issue.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 2018-07-23 21:24, Ichiroh Taki
Hello.
I'd like to change target to "JDK12".
I'd like to obtain a sponsor for this patch.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 2018-06-28 22:13, Ichiroh Takiguchi wrote:
Hello.
In my investigation, this issue only happens on 64 bit build only...
On 2018-06-28 06
Hello.
In my investigation, this issue only happens on 64 bit build only...
On 2018-06-28 06:06, Phil Race wrote:
On 06/27/2018 06:45 AM, Ichiroh Takiguchi wrote:
Hello,
I should post this mail before starting JDK11 RDP1.
Already too too late for that, but although this looks like a bug
le[cnt] = text->feedback[cnt];
(*env)->SetIntArrayRegion(env, style, 0,
text->length, (jint
*)tmpstyle);
+free(tmpstyle);
}
}
}
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
aret instanceof ComposedTextCaret) {
dot = caret.getDot();
+select(dot, dot);
// Restores original caret
exchangeCaret(caret, originalCaret);
caret.setDot(dot);
--
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
-normal--16-120-100-100-c-80-jisx0201.1976-0
[L][5] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1
===
[M] means "Missing" font, [L] means "Loaded".
On 2018-06-20 23:14, Philip Race wrote:
My question has not been answered. I don't think this is ready to
create bugid and handle it.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 2018-06-20 04:59, Naoto Sato wrote:
Please change the comment in line 680, which should also mention 13
point font.
Naoto
On 6/19/18 12:54 PM, Naoto Sato wrote:
Looks OK wrt awt_InputMethod.c change.
Naoto
On 6/19/18
ple%20Code
[2] http://javadesktop.org/articles/InputMethod/index.html
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
k please, and how I would go about obtaining a
sponsor and contributor?
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
91 matches
Mail list logo
