Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules

[Naoto Sato]

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov 
 wrote:

> Collections.sort is just a wrapper, so it is better to use an instance method 
> directly.

java.time changes look good.

-

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5229

Integrated: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current

[Naoto Sato]

On Mon, 17 May 2021 16:55:35 GMT, Naoto Sato  wrote:

> Please review the changes to the subject issue. java.util.Locale class has a 
> long-standing issue for those obsolete ISO 639 languages where its 
> normalization ends up in the obsolete codes. This change intends to flip the 
> normalization towards the current codes, providing a system property for 
> compatibility behavior. ResourceBundle class is also modified to load either 
> obsolete/current bundles. For more detail, take a look at the CSR.

This pull request has now been integrated.

Changeset: a4c46e1e
Author:Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424
Stats: 386 lines in 35 files changed: 240 ins; 41 del; 105 mod

8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current

Reviewed-by: joehw

-

PR: https://git.openjdk.java.net/jdk/pull/4069

Re: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current [v2]

[Naoto Sato]

On Tue, 18 May 2021 22:22:06 GMT, Joe Wang  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Locale's class description modification
>
> src/java.base/share/classes/java/util/Locale.java line 462:
> 
>> 460:  * backward compatible forms.
>> 461:  *
>> 462:  * The APIs added in 1.7 map between the old and new language codes,
> 
> This paragraph needs a rewrite as well it seems, esp. the part that states 
> "getLanguage and toString reflect the old code" is no longer true.

Good catch! In fact, I had modified this paragraph in my preliminary fix, but 
it slipped away somehow along the fix. Corrected the PR and CSR as well.

> test/jdk/java/util/Locale/LocaleTest.java line 683:
> 
>> 681:  * @bug 4052404 4778440 8263202
>> 682:  */
>> 683: public void TestChangedISO639Codes() {
> 
> Could probably be simplified with a DataProvider.

That would be nice, but the test is not testng based, and it would be an entire 
test rewrite which I would not do it at this time.

-

PR: https://git.openjdk.java.net/jdk/pull/4069

Re: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current [v2]

[Naoto Sato]

> Please review the changes to the subject issue. java.util.Locale class has a 
> long-standing issue for those obsolete ISO 639 languages where its 
> normalization ends up in the obsolete codes. This change intends to flip the 
> normalization towards the current codes, providing a system property for 
> compatibility behavior. ResourceBundle class is also modified to load either 
> obsolete/current bundles. For more detail, take a look at the CSR.

Naoto Sato has updated the pull request incrementally with one additional 
commit since the last revision:

  Locale's class description modification

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4069/files
  - new: https://git.openjdk.java.net/jdk/pull/4069/files/dee95bf1..0f76ac45

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4069&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4069&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4069.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4069/head:pull/4069

PR: https://git.openjdk.java.net/jdk/pull/4069

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

[Naoto Sato]

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 
> 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. 
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>  The essential change for this JEP, including the `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system 
> property is now "disallow", most of the tests calling 
> `System.setSecurityManager()` need to launched with 
> `-Djava.security.manager=allow`. This is covered in a different PR at 
> https://github.com/openjdk/jdk/pull/4071.

Reviewed i18n/java.time/charset. They all look good.

-

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

Re: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current

[Naoto Sato]

On Mon, 17 May 2021 17:14:53 GMT, Erik Joelsson  wrote:

> I see no relevant build changes to comment on as the build label was only 
> added because the buildtool java source was touched, so this looks ok from a 
> build perspective.

Removed `build` label.

-

PR: https://git.openjdk.java.net/jdk/pull/4069

RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current

[Naoto Sato]

Please review the changes to the subject issue. java.util.Locale class has a 
long-standing issue for those obsolete ISO 639 languages where its 
normalization ends up in the obsolete codes. This change intends to flip the 
normalization towards the current codes, providing a system property for 
compatibility behavior. ResourceBundle class is also modified to load either 
obsolete/current bundles. For more detail, take a look at the CSR.

-

Commit messages:
 - Added more ResourceBundleProvider tests
 - ResourceBundleProvider and test cases modifications
 - Eliminated some duplicated code
 - Changed ResourceBundle javadoc
 - Locale class description
 - renamed old resource files
 - inital commit

Changes: https://git.openjdk.java.net/jdk/pull/4069/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4069&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263202
  Stats: 382 lines in 35 files changed: 239 ins; 41 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4069.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4069/head:pull/4069

PR: https://git.openjdk.java.net/jdk/pull/4069

Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10

[Naoto Sato]

On Thu, 21 Jan 2021 21:17:53 GMT, Dmitry Markov  wrote:

>>> > > Now we will commit the composition string if there is an active client. 
>>> > > That changes eliminates the issue described in JDK-8258805. Also the 
>>> > > behaviour of AWTTextTest1 is the same as it used to be on the previous 
>>> > > versions w/o the fix.
>>> > 
>>> > 
>>> > Just to confirm: the updated behaviour is similar to what was happening 
>>> > in previous versions of Windows 10, that is if a compositing text isn't 
>>> > committed, it remains uncommitted in the text component when the focus 
>>> > changes instead of being committed as it was the case in the previous 
>>> > iteration. Is my understanding correct?
>>> 
>>> I am sorry but you didn't get it right. The behaviour, which was introduced 
>>> in previous iteration, is still in place. It is required to get rid of the 
>>> problem described in JDK-8258805
>>> The purpose of of the second iteration is to eliminate negative side effect 
>>> (more details here [#2142 
>>> (comment)](https://github.com/openjdk/jdk/pull/2142#issuecomment-763340186) 
>>> ) introduced by the first version of the fix.
>> 
>> I admit I am even more confused now. To me, the description in the comment 
>> above is nearly the same as in [JBS 
>> comment](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14391025).
>>  Is the difference that the original test case disabled IME for the middle 
>> JTextField whereas in the test case above all JTextField support IME?
>> 
>> In the updated version of the fix, we always commit the text on any focus 
>> change whether the newly focused component supports IME or not.
>
>> I admit I am even more confused now. To me, the description in the comment 
>> above is nearly the same as in [JBS 
>> comment](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14391025).
>>  Is the difference that the original test case disabled IME for the middle 
>> JTextField whereas in the test case above all JTextField support IME?
> 
> Well.. I think the main difference between tests is that the [test attached 
> to the 
> bug](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14391025)
>  uses `JTextField` (Swing) and the [test provided 
> above](https://github.com/openjdk/jdk/pull/2142#issuecomment-763491615) uses 
> `TextField` (AWT). The same input method events are processed differently for 
> Swing and AWT text components. Good example is the following test:
> 
> import java.awt.*;
> import java.awt.event.*;
> 
> public class AWTTextTest1 extends Frame {
> AWTTextTest1() {
> setTitle("AWTTextTest1");
> setLayout(new GridLayout(0, 1));
> add(new TextField());
> add(new TextField());
> addWindowListener(new WindowAdapter() {
> public void windowClosing(WindowEvent we) {
> System.exit(0);
> }
> });
> setSize(400, 300);
> setVisible(true);
> }
> public static void main(String[] args) {
> new AWTTextTest1();
> }
> }
> 
> 1. Run test (originally it uses `TextField`)
> 2. Click upper `TextField`, turn on IME, type some character (In case of 
> Japanese, type "aiu") 
> 3. Click lower `TextField`, the string is canceled. 
> 4. Replace `TextField` with `JTextField` in the test. Compile and run it 
> again.
> 5. Click upper `JTextField`, turn on IME, type some character (In case of 
> Japanese, type "aiu")
> 6. Click lower `JTextField`, the string is committed before focus transition.
> 
>> 
>> In the updated version of the fix, we always commit the text on any focus 
>> change whether the newly focused component supports IME or not.
> 
> That’s not quite right. Actually we commit the text if the current IM client 
> is “active client”. For example, `JTextField` is an “active client” but 
> `TextField`  - NOT. The status “active client” depends on the implementation 
> of getInputMethodRequests() method.

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 one behaves as the same as native Windows apps, and Swing's 
one should commit text into the component that has lost the focus.

-

PR: https://git.openjdk.java.net/jdk/pull/2142

Re: RFR: JDK-8241463 Move build tools to respective modules

[naoto . sato]

Hi Magnus,

I looked at i18n related changes:

make/CopyInterimTZDB.gmk
make/ToolsJdk.gmk
make/gendata/Gendata-java.base.gmk
make/gendata/GendataBreakIterator.gmk
make/gendata/GendataTZDB.gmk
make/gensrc/GensrcCharacterData.gmk
make/gensrc/GensrcEmojiData.gmk

They look ok to me.

The *.java changes should have copyright year update.

As to charsetmapping and cldrconverter, I believe they can reside in 
java.base, as jdk.charsets and jdk.localedata modules depend on it.


Naoto

On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote:
The build tools (small java tools that are run during the build to 
generate source code, or data, needed in the JDK) have historically been 
placed in the "make" directory. This maybe made sense long time ago, but 
does not do so anymore.


Instead, the build tools source code should move the the module that 
needs them. For instance, compilefontconfig should move to java.desktop, 
etc.


There are multiple reasons for this:

* Currently we build *all* build tools at once, which mean that we 
cannot compile java.base until e.g. the compilefontconfig tool is 
compiled, even though it is not needed.


* If a build tool, e.g. compilefontconfig is modified, all build tools 
are recompiled, which triggers a rebuild of more or less the entire JDK. 
This makes development of the build tools unnecessary tedious.


* When the build tools are modified, the group owning the corresponding 
module is the proper review instance, not the build team. But since they 
reside under "make", the review mails often include build-dev, but this 
is mostly noise for us. With this move, the ownership is made clear.


In this patch, I have not modified how and when the build tools are 
compiled, but this shuffle is the prerequisite for continuing with that 
in a follow-up patch.


I have also moved the build tools to the org.openjdk.buildtools.* 
package name space (inspired by Skara), instead of the strangely named 
build.tools.* name space.


A few build tools are not moved in this patch. Two of them, 
charsetmapping and cldrconverter, are shared between two modules. (I 
think they should move to modules nevertheless, but they need some more 
thought to make sure I do this right.) The rest are tools that are 
needed for the build in general, like linking or javadoc support. I'll 
move this to a better location too, but in a separate patch.


Bug: https://bugs.openjdk.java.net/browse/JDK-8241463
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 



/Magnus

Re: RFR: 8212678 Windows IME related patch

[naoto . sato]

+1

Naoto

On 2/13/19 4:36 PM, Sergey Bylokhov wrote:

Hi, Ichiroh.

The fix looks fine, it will be good if someone from i18n team will take 
a look.


On 04/02/2019 04:53, Ichiroh Takiguchi wrote:

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 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/

3 issues were combined.
2 issues are recreatable on English Windows.

Screen shots and movies are attached into JDK-8212678.
Please 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/webrev.00/

Test instruction is in JDK-8212678.
This fix may improve CJK IME operation.

I'd like to obtain a sponsor for this issue.

Thanks,
Ichiroh 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 can fix following issues.
A: Cannot display surrogate pair character on Windows floating 
IME window for passive component
B: Control Windows IME status by using InputSubset and 
UnicodeBlock for CJK countries

C: Check preedit string availability for Windows Chinese IME

To recreate each issue.

Issue A:
1. Run SwingSet2 Java demo program with Japanese IME.
2. Click InternalFrameDemo's "Frame 0".
3. Turn on Japanese IME, then type "2000B" and press F5 key.
The character is not displayed properly. [1]

Issue B:
Test program (ImSubsetsTest.java) is as follow:
http://cr.openjdk.java.net/~aleonard/winime/ImSubsetsTest.java

1. Compile and run ImSubsetsTest with CJK IMEs
2. Select language (ja:Japanese, ko:Korean, zh: Chinese).
Windows IME (same langugae's one) should be turned on.
3. Click  JTextField (active component) or JButton (passive 
component)

(Please check IM status is changed or not)
4. Click different color's JTextField (active component) or 
JButton (passive component)

(Please check IM status is changed or not)
5. Following operations did not work
Korean IME : HANJA->LATIN_DIGIT,BASIC_LATIN
Chinese IME : FULLWIDTH_DIGITS->LATIN_DIGIT,BASIC_LATIN

Issue C:
Test program is as follows:
==
import javax.swing.*;

public class IMFTestA extends JFrame {
  IMFTestA(int width, int height, int x, int y) {
    super("JTextArea");
    add(new JTextArea());
    setSize(width, height);
    setLocation(x, y);
    setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    setVisible(true);
  }
  public static void main(String[] args) {
    new IMFTestA(300, 200, 0, 0);
    new IMFTestA(300, 200, 300, 0);
  }
}
==

On Chinese IME (Microsoft Pinyin ABC),
1. Compile and run IMFTestA
2. Click one of JTextArea window, turn ON Chinese IME
3. Click the other window, turn ON Chinese IME
4. Type "nihao", then preedit string is displayed
5. Click the other window, turn OFF Chinese IME
6. Click the other window, preedit string is still displayed but 
it's not convertable


Reason:
Issue A, proper font is not specified for passive component
Issue B, IME mode setting for CJK Windows IME is not correct
Issue C, Chinese Windows IME shares IME status between windows, 
Java needs to check preedit string is available or not


I'd like contribute following 3 files:
M src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java
M src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
M src/java.desktop/windows/native/libawt/windows/awt_InputMethod.cpp
http://cr.openjdk.java.net/~aleonard/winime/webrev.00/

I appreciate any feedback please, and how I would go about 
obtaining a sponsor and contributor?


[1] http://unicode.org/cgi-bin/GetUnihanData.pl?codepoint=2000B

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

Re: Fw: [PATCH] JDK-8213183: InputMethod cannot be used after its restarting

[naoto . sato]

Looks good to me.

Naoto

On 12/11/18 8:32 PM, Toshio 5 Nakamura wrote:

Hello Naoto,

Thank you for your review.

The updated webrev:
http://cr.openjdk.java.net/~tnakamura/8213183/webrev.02/

Thanks,
Toshio Nakamura

Naoto Sato  wrote on 2018/12/12 06:27:46:

 > From: Naoto Sato 
 > To: Toshio 5 Nakamura , awt-
 > d...@openjdk.java.net, i18n-...@openjdk.java.net
 > Date: 2018/12/12 06:30
 > Subject: Re:   Fw: [PATCH] JDK-8213183:
 > InputMethod cannot be used after its restarting
 >
 > Hello,
 >
 > I would rather not create a new test directory ReconnectTest. Instead,
 > moving the test under InputContext would just be fine. Other than that,
 > looks good to me.
 >
 > Naoto
 >
 > On 12/4/18 6:45 PM, Toshio 5 Nakamura wrote:
 > > Hello,
 > >
 > > Can anyone support this proposal? I appreciate any suggestion or 
comment.

 > >
 > > issue:
 > > INVALID URI REMOVED
 > 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213183&d=DwICaQ&c=jf_iaSHvJObTbx-

 > siA1ZOg&r=EVbFABcgo-X99_TGI2-
 > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx-
 > KQAP0ap59aIgx7JdMXnkMf0&s=q6uPI3Ypu4juvcyBI8aEenYXLO-yGglZe9fOzYWHni4&e=
 > > webrev:
 > > INVALID URI REMOVED
 > u=http-3A__cr.openjdk.java.net_-7Etnakamura_8213183_webrev.
 > 01_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-
 > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx-
 > KQAP0ap59aIgx7JdMXnkMf0&s=78XQhanHugJH88R5X5xh_QIq54Wzi4ZR52f4iTjMhH8&e=
 > >
 > > Fix descriptions:
 > > - XSelectInput() in XMSelection.java may erase existing
 > >    XRegisterIMInstantiateCallback entry. It should keep the current 
masks.

 > > - All input method data in the linked list should be cleared when
 > >    DestroyXIMCallback() was called.
 > >
 > > Best regards,
 > > Toshio Nakamura
 > >
 > > "awt-dev"  wrote on 2018/11/22 
15:48:10:

 > >
 > >> From: "Toshio 5 Nakamura" 
 > >> To: awt-dev@openjdk.java.net, i18n-...@openjdk.java.net
 > >> Date: 2018/11/22 15:50
 > >> Subject:  Fw: [PATCH] JDK-8213183: InputMethod cannot be
 > >> used after its restarting
 > >> Sent by: "awt-dev" 
 > >>
 > >> Ping.
 > >>
 > >> Thanks,
 > >> Toshio Nakamura
 > >>
 > >> "awt-dev"  wrote on 2018/11/15
 > > 17:15:25:
 > >>
 > >>> From: "Toshio 5 Nakamura" 
 > >>> To: awt-dev@openjdk.java.net, i18n-...@openjdk.java.net
 > >>> Date: 2018/11/15 17:16
 > >>> Subject: Re:  [PATCH] JDK-8213183: InputMethod cannot be
 > >>> used after its restarting
 > >>> Sent by: "awt-dev" 
 > >>>
 > >>> Hello,
 > >>>
 > >>> I'd like to re-propose minimized patch in this thread.
 > >>>
 > >>> The key fix of this patch is for XMSelection.java. Its initScreen()
 > > cleared
 > >>> previous XRegisterIMInstantiateCallback() entry, but it should 
keep the

 > >>> current mask. By this change only, we can reuse Input Method after
 > >>> changing focus.
 > >>> (Original patch didn't need focus change, but it may be hard to
 > > bereviewed.)
 > >>>
 > >>> Additionally, this change may unveil a potential problem in
 > >> awt_InputMethod.c.
 > >>> It needs to clear all pX11IMData, not only the current one. Without
 > >>> the change,
 > >>> multi-window application with IM may crash after IM restart.
 > >>>
 > >>> So, I'd like to propose only two parts in this thread.
 > >>> Can I obtain a sponsor for this minimized fix?
 > >>>
 > >>> Revised webrev:
 > >>> INVALID URI REMOVED
 > u=http-3A__cr.openjdk.java.net_-7Etnakamura_8213183_webrev.
 > 01_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2-
 > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx-
 > KQAP0ap59aIgx7JdMXnkMf0&s=78XQhanHugJH88R5X5xh_QIq54Wzi4ZR52f4iTjMhH8&e=
 > >>>
 > >>> Thanks,
 > >>> Toshio Nakamura
 > >>>
 > >>> From: "Toshio 5 Nakamura" 
 > >>> To: Sergey Bylokhov 
 > >>> Cc: awt-dev@openjdk.java.net, i18n-...@openjdk.java.net
 > >>> Date: 2018/11/12 20:22
 > >>> Subject: Re:  [PATCH] JDK-8213183: InputMethod cannot be
 > >>> used after its restarting
 > >>> Sent by: "awt-dev" 
 > >>>
 > >>>
 > >>>
 > >>> Hi Sergey,
 > >>>
 > >

Re: Fw: [PATCH] JDK-8213183: InputMethod cannot be used after its restarting

[Naoto Sato]

Hello,

I would rather not create a new test directory ReconnectTest. Instead, 
moving the test under InputContext would just be fine. Other than that, 
looks good to me.


Naoto

On 12/4/18 6:45 PM, Toshio 5 Nakamura wrote:

Hello,

Can anyone support this proposal? I appreciate any suggestion or comment.

issue:
https://bugs.openjdk.java.net/browse/JDK-8213183
webrev:
http://cr.openjdk.java.net/~tnakamura/8213183/webrev.01/

Fix descriptions:
- XSelectInput() in XMSelection.java may erase existing
   XRegisterIMInstantiateCallback entry. It should keep the current masks.
- All input method data in the linked list should be cleared when
   DestroyXIMCallback() was called.

Best regards,
Toshio Nakamura

"awt-dev"  wrote on 2018/11/22 15:48:10:


From: "Toshio 5 Nakamura" 
To: awt-dev@openjdk.java.net, i18n-...@openjdk.java.net
Date: 2018/11/22 15:50
Subject:  Fw: [PATCH] JDK-8213183: InputMethod cannot be
used after its restarting
Sent by: "awt-dev" 

Ping.

Thanks,
Toshio Nakamura

"awt-dev"  wrote on 2018/11/15

17:15:25:



From: "Toshio 5 Nakamura" 
To: awt-dev@openjdk.java.net, i18n-...@openjdk.java.net
Date: 2018/11/15 17:16
Subject: Re:  [PATCH] JDK-8213183: InputMethod cannot be
used after its restarting
Sent by: "awt-dev" 

Hello,

I'd like to re-propose minimized patch in this thread.

The key fix of this patch is for XMSelection.java. Its initScreen()

cleared

previous XRegisterIMInstantiateCallback() entry, but it should keep the
current mask. By this change only, we can reuse Input Method after
changing focus.
(Original patch didn't need focus change, but it may be hard to

bereviewed.)


Additionally, this change may unveil a potential problem in

awt_InputMethod.c.

It needs to clear all pX11IMData, not only the current one. Without
the change,
multi-window application with IM may crash after IM restart.

So, I'd like to propose only two parts in this thread.
Can I obtain a sponsor for this minimized fix?

Revised webrev:
http://cr.openjdk.java.net/~tnakamura/8213183/webrev.01/

Thanks,
Toshio Nakamura

From: "Toshio 5 Nakamura" 
To: Sergey Bylokhov 
Cc: awt-dev@openjdk.java.net, i18n-...@openjdk.java.net
Date: 2018/11/12 20:22
Subject: Re:  [PATCH] JDK-8213183: InputMethod cannot be
used after its restarting
Sent by: "awt-dev" 



Hi Sergey,

Thank you for your reply. Yes, I've added the steps to the bug.
https://bugs.openjdk.java.net/browse/JDK-8213183

Please let me know if you have any question or any advice.

Thanks,
Toshio Nakamura

From: Sergey Bylokhov 
To: Toshio 5 Nakamura , awt-
d...@openjdk.java.net, i18n-...@openjdk.java.net
Date: 2018/11/10 12:46
Subject: Re:  [PATCH] JDK-8213183: InputMethod cannot be
used after its restarting



Hi, Toshio.

Can you please add the steps to reproduce to the bug description.

On 06/11/2018 01:19, Toshio 5 Nakamura wrote:

Hello,

Can I obtain a sponsor of this proposal about InputMethod issue on

Linux?


Bug:
https://bugs.openjdk.java.net/browse/JDK-8213183
Webrev:
http://cr.openjdk.java.net/~tnakamura/8213183/webrev.00/

I've got an author role and filled the bug report.
Please refer the attached mail about the detail of this patch.

Best Regards,
Toshio Nakamura


--
Best regards, Sergey.

Re: RFR[12]: 8211393 Memory leak issue on awt_InputMethod.c

[Naoto Sato]

Looks good to me.

Naoto

On 10/2/18 9:30 AM, Ichiroh Takiguchi wrote:

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 Takiguchi wrote:

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: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 -
and the correct fix -
the bug has been there forever .. since JDK 1.2  in 1998 !
That makes it a 20 year old bug, so I don't think we need to treat 
it as urgent

for JDK 11.

-phil.



I found memory leak issue on awt_InputMethod.c.

See src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c.
On line 1117, memory area was allocated by malloc(), but free() is 
missing

===
  1099  if (text->feedback != NULL) {
  1100  int cnt;
  1101  jint *tmpstyle;
  1102
  1103  style = (*env)->NewIntArray(env, text->length);
  1104  if (JNU_IsNull(env, style)) {
  1105  (*env)->ExceptionClear(env);
  1106  THROW_OUT_OF_MEMORY_ERROR();
  1107  goto finally;
  1108  }
  1109
  1110  if (sizeof(XIMFeedback) == sizeof(jint)) {
    /*
  1112   * Optimization to avoid copying the array
  1113   */
  1114  (*env)->SetIntArrayRegion(env, style, 0,
  1115    text->length, 
(jint *)text->feedback);

  1116  } else {
  1117  tmpstyle  = (jint 
*)malloc(sizeof(jint)*(text->length));

  1118  if (tmpstyle == (jint *) NULL) {
  1119  THROW_OUT_OF_MEMORY_ERROR();
  1120  goto finally;
  1121  }
  1122  for (cnt = 0; cnt < (int)text->length; cnt++)
  1123  tmpstyle[cnt] = text->feedback[cnt];
  1124  (*env)->SetIntArrayRegion(env, style, 0,
  1125    text->length, 
(jint *)tmpstyle);

  1126  }
  1127  }
===
In my investigation, malloc() was called on RHEL7 x86_64 with 
Japanese Input Method.


I'd like to obtain a sponsor for this patch.

--- 
old/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c 
2018-06-27 02:03:48.134991703 +0900
+++ 
new/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c 
2018-06-27 02:03:47.493005265 +0900

@@ -1148,6 +1148,7 @@
 tmpstyle[cnt] = text->feedback[cnt];
 (*env)->SetIntArrayRegion(env, style, 0,
   text->length, (jint 
*)tmpstyle);

+    free(tmpstyle);
 }
 }
 }
--- 
old/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c 
2018-06-27 02:03:49.040972563 +0900
+++ 
new/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c 
2018-06-27 02:03:48.391986274 +0900

@@ -1123,6 +1123,7 @@
 tmpstyle[cnt] = text->feedback[cnt];
 (*env)->SetIntArrayRegion(env, style, 0,
   text->length, (jint 
*)tmpstyle);

+    free(tmpstyle);
 }
 }
 }


Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

Re: Proposal:X11 default visual support for IM status window on VNC

[Naoto Sato]

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 11:32 AM, Phil Race wrote:

Where's the bug ID ?

The review should have a bug ID in the subject line so we can all find 
it later !


Is this changing the default visual  for all WIndows, not just the IM 
status window?
I think we need to understand the implications before this can be 
accepted.


Similarly for the fontset change .. this might change what others get.
The fontset spec. there seems very loose to me ..

I think I18N-DEV should be asked about this too.

-phil.

On 06/19/2018 11:07 AM, Sergey Bylokhov wrote:
Looks fine, if there are no other comments I'll push the fix using 
the new bugid.


On 06/06/2018 17:54, Ichiroh Takiguchi wrote:

Hello Sergey.
Thank you for your review.

Could you review following patch ?
http://cr.openjdk.java.net/~aleonard/defvis/webrev.01/

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-06-06 07:15, Sergey Bylokhov wrote:

Hi, Ichiroh.
The approach looks fine, but maybe it is possible to decrees code
duplication in findWithTemplate(). After the fix it will have two
similar loops.

On 24/05/2018 22:24, Ichiroh Takiguchi wrote:

Hello,
IBM would like to contribute X11 default visual support for IM 
status window patch to OpenJDK project.


Issue:
Java's Native IM status window is not displayed even if it's there.
Because of this issue, user cannot get proper visual feedback 
during key input operation.

We found this issue on Tiger VNC.

Reason:
Java may pick up unexpected visual for Java's Native IM status 
window when  Xserver supports multiple visual.


Workaround:
X11 default visual can be changed by FORCEDEFVIS environment 
variable, but it's not easy to find out default visual id.


I'd like contribute following 2 files:
M src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c
(Change X11 visual setting)
M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
(Support 13 point X11 misc fonts (like k14 font for Japanese), 
since the fonts may defined for unscaled fonts.)


webrev files are in
http://cr.openjdk.java.net/~aleonard/defvis/

I appreciate any feedback please, and how I would go about 
obtaining a sponsor and contributor?


Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

Re: Proposal:X11 default visual support for IM status window on VNC

[Naoto Sato]

Looks OK wrt awt_InputMethod.c change.

Naoto

On 6/19/18 11:32 AM, Phil Race wrote:

Where's the bug ID ?

The review should have a bug ID in the subject line so we can all find 
it later !


Is this changing the default visual  for all WIndows, not just the IM 
status window?

I think we need to understand the implications before this can be accepted.

Similarly for the fontset change .. this might change what others get.
The fontset spec. there seems very loose to me ..

I think I18N-DEV should be asked about this too.

-phil.

On 06/19/2018 11:07 AM, Sergey Bylokhov wrote:
Looks fine, if there are no other comments I'll push the fix using the 
new bugid.


On 06/06/2018 17:54, Ichiroh Takiguchi wrote:

Hello Sergey.
Thank you for your review.

Could you review following patch ?
http://cr.openjdk.java.net/~aleonard/defvis/webrev.01/

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-06-06 07:15, Sergey Bylokhov wrote:

Hi, Ichiroh.
The approach looks fine, but maybe it is possible to decrees code
duplication in findWithTemplate(). After the fix it will have two
similar loops.

On 24/05/2018 22:24, Ichiroh Takiguchi wrote:

Hello,
IBM would like to contribute X11 default visual support for IM 
status window patch to OpenJDK project.


Issue:
Java's Native IM status window is not displayed even if it's there.
Because of this issue, user cannot get proper visual feedback 
during key input operation.

We found this issue on Tiger VNC.

Reason:
Java may pick up unexpected visual for Java's Native IM status 
window when  Xserver supports multiple visual.


Workaround:
X11 default visual can be changed by FORCEDEFVIS environment 
variable, but it's not easy to find out default visual id.


I'd like contribute following 2 files:
M src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c
(Change X11 visual setting)
M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
(Support 13 point X11 misc fonts (like k14 font for Japanese), 
since the fonts may defined for unscaled fonts.)


webrev files are in
http://cr.openjdk.java.net/~aleonard/defvis/

I appreciate any feedback please, and how I would go about 
obtaining a sponsor and contributor?


Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

Re: JDK10 RFR of JDK-JDK-8168767: java.awt.im.InputContext API doc has a reference to extensions

[Naoto Sato]

+1

Naoto

On 11/16/17 9:49 PM, Rachna Goel wrote:

Hi,

Kindly review API Doc fix for java.awt.im.InputContext.

JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8168767

Webrev: http://cr.openjdk.java.net/~rgoel/8191123/webrev/

CSR: https://bugs.openjdk.java.net/browse/JDK-8191123

Re: The input method handling

[Naoto Sato]

What I meant by that is the "porting" part of the code, not the Apple 
JDK itself. IIRC, the initial porting from Apple JDK to Oracle JDK was 
done by folks at Apple, and that piece of comment was included since the 
initial port:


https://bugs.openjdk.java.net/browse/JDK-7113349

Naoto

On 12/12/14, 3:07 AM, Sergey Malenkov wrote:

I'm not sure that this is the Apple's code, because Oracle JDK works
slightly different from Apple JDK.

On Fri, Dec 12, 2014 at 12:04 AM, Naoto Sato  wrote:

Honestly I cannot judge whether that is OK or not, because I don't know the
original intention of the comment I quoted in the previous mail. Maybe there
were some corner cases and that's what I wanted to know. Maybe asking the
original authors of the code (at Apple?) about this would help?

Naoto


On 12/11/14 3:15 AM, Sergey Malenkov wrote:


Hi Naoto,

I think it may affect some Chinese symbols, which are represented by 2
Java-characters, but I don't have a corresponding keyboard to check. I
could modify the fix: create jstring before the if-statement and check
for its length. This looks safe and helps to determine a complex (in
Java terms) Unicode value. What do you think?




On Wed, Dec 10, 2014 at 10:21 PM, Naoto Sato 
wrote:


Hi Sergey,

It seems that the comment specifically mentions to go this route "when
the
string to insert is a complex Unicode value." and your change would break
it. Have you investigated what it means?

Also, if the change turns OK, you probably would want to change the
variable
name from "utf8Length" to something more appropriate.

Naoto


On 12/10/14, 9:56 AM, Sergey Malenkov wrote:



Hi all,

In Oracle JDK the input method handling is slightly different from
Apple JDK. And this is a reason of some issues in IntelliJ IDEA. I
found out that the insertText method in the following file uses
lengthOfBytesUsingEncoding instead of length in characters:



http://hg.openjdk.java.net/jdk9/dev/jdk/file/e5b66323ae45/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m

This means that almost every Alt+Key combination generates
InputMethodEvent instead of pair of KeyEvent for PRESSED and TYPED. It
makes impossible to support custom shortcuts for all Alt+Key and
Shift+Alt+Key combinations on Mac, what is one of the reasons why
users do not want to migrate from Apple JDK to Oracle JDK on Mac.

I suggest to apply the following patch to the AWTView.m file:

--- a/src/macosx/native/sun/awt/AWTView.m Wed Dec 10 17:20:48 2014 +0400
+++ b/src/macosx/native/sun/awt/AWTView.m Wed Dec 10 19:51:56 2014 +0300
@@ -889,7 +889,7 @@
// text, or 'text in progress'.  We also need to send the event
if we get an insert text out of the blue!
// (i.e., when the user uses the Character palette or Inkwell),
or when the string to insert is a complex
// Unicode value.
-NSUInteger utf8Length = [aString
lengthOfBytesUsingEncoding:NSUTF8StringEncoding];
+NSUInteger utf8Length = [aString length];

if ([self hasMarkedText] || !fProcessingKeystroke || (utf8Length



1)) {
JNIEnv *env = [ThreadUtilities getJNIEnv];

It makes the input method handling  more compatible with Apple JDK and
allows us to provide users the same behavior with Oracle JDK.

Do you have any objections?
Are there some hidden pitfalls?

Re: The input method handling

[Naoto Sato]

Honestly I cannot judge whether that is OK or not, because I don't know 
the original intention of the comment I quoted in the previous mail. 
Maybe there were some corner cases and that's what I wanted to know. 
Maybe asking the original authors of the code (at Apple?) about this 
would help?


Naoto

On 12/11/14 3:15 AM, Sergey Malenkov wrote:

Hi Naoto,

I think it may affect some Chinese symbols, which are represented by 2
Java-characters, but I don't have a corresponding keyboard to check. I
could modify the fix: create jstring before the if-statement and check
for its length. This looks safe and helps to determine a complex (in
Java terms) Unicode value. What do you think?




On Wed, Dec 10, 2014 at 10:21 PM, Naoto Sato  wrote:

Hi Sergey,

It seems that the comment specifically mentions to go this route "when the
string to insert is a complex Unicode value." and your change would break
it. Have you investigated what it means?

Also, if the change turns OK, you probably would want to change the variable
name from "utf8Length" to something more appropriate.

Naoto


On 12/10/14, 9:56 AM, Sergey Malenkov wrote:


Hi all,

In Oracle JDK the input method handling is slightly different from
Apple JDK. And this is a reason of some issues in IntelliJ IDEA. I
found out that the insertText method in the following file uses
lengthOfBytesUsingEncoding instead of length in characters:


http://hg.openjdk.java.net/jdk9/dev/jdk/file/e5b66323ae45/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m

This means that almost every Alt+Key combination generates
InputMethodEvent instead of pair of KeyEvent for PRESSED and TYPED. It
makes impossible to support custom shortcuts for all Alt+Key and
Shift+Alt+Key combinations on Mac, what is one of the reasons why
users do not want to migrate from Apple JDK to Oracle JDK on Mac.

I suggest to apply the following patch to the AWTView.m file:

--- a/src/macosx/native/sun/awt/AWTView.m Wed Dec 10 17:20:48 2014 +0400
+++ b/src/macosx/native/sun/awt/AWTView.m Wed Dec 10 19:51:56 2014 +0300
@@ -889,7 +889,7 @@
   // text, or 'text in progress'.  We also need to send the event
if we get an insert text out of the blue!
   // (i.e., when the user uses the Character palette or Inkwell),
or when the string to insert is a complex
   // Unicode value.
-NSUInteger utf8Length = [aString
lengthOfBytesUsingEncoding:NSUTF8StringEncoding];
+NSUInteger utf8Length = [aString length];

   if ([self hasMarkedText] || !fProcessingKeystroke || (utf8Length >
1)) {
   JNIEnv *env = [ThreadUtilities getJNIEnv];

It makes the input method handling  more compatible with Apple JDK and
allows us to provide users the same behavior with Oracle JDK.

Do you have any objections?
Are there some hidden pitfalls?

Re: The input method handling

[Naoto Sato]

Hi Sergey,

It seems that the comment specifically mentions to go this route "when 
the string to insert is a complex Unicode value." and your change would 
break it. Have you investigated what it means?


Also, if the change turns OK, you probably would want to change the 
variable name from "utf8Length" to something more appropriate.


Naoto

On 12/10/14, 9:56 AM, Sergey Malenkov wrote:

Hi all,

In Oracle JDK the input method handling is slightly different from
Apple JDK. And this is a reason of some issues in IntelliJ IDEA. I
found out that the insertText method in the following file uses
lengthOfBytesUsingEncoding instead of length in characters:

http://hg.openjdk.java.net/jdk9/dev/jdk/file/e5b66323ae45/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m

This means that almost every Alt+Key combination generates
InputMethodEvent instead of pair of KeyEvent for PRESSED and TYPED. It
makes impossible to support custom shortcuts for all Alt+Key and
Shift+Alt+Key combinations on Mac, what is one of the reasons why
users do not want to migrate from Apple JDK to Oracle JDK on Mac.

I suggest to apply the following patch to the AWTView.m file:

--- a/src/macosx/native/sun/awt/AWTView.m Wed Dec 10 17:20:48 2014 +0400
+++ b/src/macosx/native/sun/awt/AWTView.m Wed Dec 10 19:51:56 2014 +0300
@@ -889,7 +889,7 @@
  // text, or 'text in progress'.  We also need to send the event
if we get an insert text out of the blue!
  // (i.e., when the user uses the Character palette or Inkwell),
or when the string to insert is a complex
  // Unicode value.
-NSUInteger utf8Length = [aString
lengthOfBytesUsingEncoding:NSUTF8StringEncoding];
+NSUInteger utf8Length = [aString length];

  if ([self hasMarkedText] || !fProcessingKeystroke || (utf8Length > 1)) {
  JNIEnv *env = [ThreadUtilities getJNIEnv];

It makes the input method handling  more compatible with Apple JDK and
allows us to provide users the same behavior with Oracle JDK.

Do you have any objections?
Are there some hidden pitfalls?

Re: CFV: New jdk9 Committer: David DeHaven

[Naoto Sato]

Vote: yes

Naoto

On 5/19/26 H, 12:51 PM, Anthony Petrov wrote:

I hereby nominate David DeHaven (OpenJDK user name: ddehaven) for jdk9
Committer

David has contributed a number of patches to JDK 7u, 8, 8u, and 9. Also,
he has reviewed many fixes that went into those releases. The AWT Group
particularly values his deep expertise in Mac OS X, which helped us a
lot when we were porting JDK 7u4 to that platform.

Here's some of his contributions:

http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=ddehaven
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/log?rev=ddehaven
http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/log?rev=ddehaven


Votes are due by June 02, 2014.

Only current jdk9 Committers [1] are eligible to vote [2] on this
nomination.

For Lazy Consensus voting instructions, see [3].


[1] http://openjdk.java.net/census#jdk9
[2] http://openjdk.java.net/projects/#committer-vote
[3] http://openjdk.java.net/bylaws#lazy-consensus

--
best regards,
Anthony

Re: Preedit string is still exist after focus change operation

[Naoto Sato]

Hi Deven,

Looks like the webrev link is broken.

Anyway, I briefly looked at the original webrev (embedded down below). I 
believe that the endComposition on switching the focus to different 
input context should work on any platforms that Java supports (does not 
matter the pre-edit is discarded or committed), so fixing Windows 
depending code does not sound right to me. This issue should be fixed at 
the Java (platform independent) level.


Naoto

On 6/30/13 11:20 PM, Deven You wrote:

Hi Anthony and Naoto,

Thanks very much for your suggestions and help!

I have created a jtreg test[1] according to the example of
SpuriousExitEnter.java.

The more detail information about the test could still be inspected by [2].

Please review the updated webrev[1].

Thanks a lot!

[1] http://cr.openjdk.java.net/~youdwei/ojdk-687/webrev0.2/
[2] http://cr.openjdk.java.net/~youdwei/ojdk-687/IMF4/
On 05/15/2013 02:37 AM, Naoto Sato wrote:

It does sound like a bug. Moved the web incidents into a JDK bug
(8014558)

Naoto

On 5/14/13 5:30 AM, Anthony Petrov wrote:

Hi Deven,

I'm copying i18n-dev@ because they manage the IM code.

As to a test, jtreg supports manual tests. See [1] for a lot of tips
about using manual tests. An example of a manual test is at:

jdk/test/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter.java


[1] http://openjdk.java.net/jtreg/faq.html

--
best regards,
Anthony

On 05/09/2013 11:33 AM, Deven You wrote:

Hi All,

I found there is a problem with our IMF(Input Methods Framework) when
dealing with DBCS input like Chinese and Japanese on Windows 7 32bit
env.

The simple scenario is if your application has 2 windows and then:

1: focus on first window, change to microsoft pinyin input method
Chinese mode.
2: Input some words, leave some words in preedit string not committed.
3: Move focus to the other window, change to English mode and input
something
4: Move back to the first window. It is in English mode, but the
preedit
string is still there(this is the bug).
5: Delete the preedit string with backspace and press enter, it appears
again.

I have raised  a sunbug for this issue, the internal ID is: 9002399

I have written a test case[1] to reproduce this problem on windows 7 32
bit machine with latest OpenJDK 8.
Since I am not clear how to run this test case as a jtreg, I just
put it
to cr.openjdk.java.net. There are several files within this test case:

actual-step*.pngSteps reproducing the bug. (can
not )
JTextAreaTest3.java The test case.
Readme.txt  Simple description
IMF_04_69120.txtMore detail.

I also made possible patch[2] for this problem.

Please anyone take a look at this issue and give your suggestion.

[1] http://cr.openjdk.java.net/~youdwei/ojdk-687/IMF4/
<http://cr.openjdk.java.net/%7Eyoudwei/ojdk-687/IMF4/>
[2] http://cr.openjdk.java.net/~youdwei/ojdk-687/webrev/
<http://cr.openjdk.java.net/%7Eyoudwei/ojdk-687/webrev/>

Thanks a lot!

Re: Request for review: 7006052: awt_InputMethod.c cleanup is needed

[Naoto Sato]

Hi Anthony,

Thank you for the review. I initially thought I would remove XAWT_HACK 
from makefiles, but noticed XAWT was still there as well. So I just left 
the compiler flag as it was. I think it's up to AWT team to remove those 
flags, as I am not sure the original intention of XAWT_HACK ifdefs.


Naoto

On 5/31/13 4:19 AM, Anthony Petrov wrote:

Hi Naoto,

I'm not an expert in this code, but the changes look good to me.

Should we also remove the definition of the XAWT_HACK symbol from our
makefiles if we don't use it anymore (this needs to be checked though)?

--
best regards,
Anthony

On 05/30/2013 03:31 AM, Naoto Sato wrote:

Hello,

Please review the fix for the following bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7006052

Webrev for the fix is located here, which simply removes "XAWT_HACK"
ifdefs ("XAWT" ifdefs are already removed):

http://cr.openjdk.java.net/~naoto/7006052/webrev.00/

Naoto

Request for review: 7006052: awt_InputMethod.c cleanup is needed

[Naoto Sato]

Hello,

Please review the fix for the following bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7006052

Webrev for the fix is located here, which simply removes "XAWT_HACK" 
ifdefs ("XAWT" ifdefs are already removed):


http://cr.openjdk.java.net/~naoto/7006052/webrev.00/

Naoto

Re: Preedit string is still exist after focus change operation

[Naoto Sato]

It does sound like a bug. Moved the web incidents into a JDK bug (8014558)

Naoto

On 5/14/13 5:30 AM, Anthony Petrov wrote:

Hi Deven,

I'm copying i18n-dev@ because they manage the IM code.

As to a test, jtreg supports manual tests. See [1] for a lot of tips
about using manual tests. An example of a manual test is at:

jdk/test/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter.java

[1] http://openjdk.java.net/jtreg/faq.html

--
best regards,
Anthony

On 05/09/2013 11:33 AM, Deven You wrote:

Hi All,

I found there is a problem with our IMF(Input Methods Framework) when
dealing with DBCS input like Chinese and Japanese on Windows 7 32bit env.

The simple scenario is if your application has 2 windows and then:

1: focus on first window, change to microsoft pinyin input method
Chinese mode.
2: Input some words, leave some words in preedit string not committed.
3: Move focus to the other window, change to English mode and input
something
4: Move back to the first window. It is in English mode, but the preedit
string is still there(this is the bug).
5: Delete the preedit string with backspace and press enter, it appears
again.

I have raised  a sunbug for this issue, the internal ID is: 9002399

I have written a test case[1] to reproduce this problem on windows 7 32
bit machine with latest OpenJDK 8.
Since I am not clear how to run this test case as a jtreg, I just put it
to cr.openjdk.java.net. There are several files within this test case:

actual-step*.pngSteps reproducing the bug. (can not )
JTextAreaTest3.java The test case.
Readme.txt  Simple description
IMF_04_69120.txtMore detail.

I also made possible patch[2] for this problem.

Please anyone take a look at this issue and give your suggestion.

[1] http://cr.openjdk.java.net/~youdwei/ojdk-687/IMF4/

[2] http://cr.openjdk.java.net/~youdwei/ojdk-687/webrev/


Thanks a lot!

Re: [7u12] Review request for 6789984: JPasswordField can not receive keyboard input

[Naoto Sato]

Looks good to me.

Naoto

On 11/16/12 5:57 AM, Anton Litvinov wrote:

Hello Naoto,

Since you approved this fix for JDK 8 originally, could you please
review this fix for JDK 7 also. Currently this request has one approval
from AWT team and the second lacking approval is a prerequisite for a
subsequent push approval request.

Thank you,
Anton

On 11/15/2012 5:51 PM, Anthony Petrov wrote:

(also cc'ing i18n-dev@)

Approved, provided the code compiles and works as expected in the 7u
release.

--
best regards,
Anthony

On 11/15/12 12:43, Anton Litvinov wrote:

Hello,

Please review the following fix for a bug. It is a backport of the fix
which is already reviewed and committed into JDK 8 repository. This fix
is identical to the fix for JDK 8.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.02
JDK 8 changeset:
http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f32a0aee7bb9

Thank you,
Anton

Re: [8] Review request for 6789984: JPasswordField can not receive keyboard input

[Naoto Sato]

The fix looks good. I'd suggest modifying the comment for 
sun.awt.im.InputMethodAdapter.stopListening() too, since the method is 
now being issued even when Java input method is not active.


Also, please make sure there is no issue on switching the input method 
between the input method adapter and a Java input method, such as 
CodePointInputMethod which is in the JDK demo directory.


Thanks!
Naoto

On 11/11/12 12:07 PM, Anton Litvinov wrote:

Hello Naoto,

Could you, please, review a modified version of the fix, where a former
duplicating code "endComposition();disableInputMethod()" was substituted
for one call to "stopListening()". Also larger testing of the fix was
done on Linux and Windows machine.

Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.01

I came to a conclusion that substitution of call to
"disableInputMethod()" for "stopListening()" in
"sun.awt.im.InputContext", which is code shared between different
platforms, will not lead to any changes on platforms other than Linux
and Solaris. In order to prove this the following facts are provided:

 1. Windows implementation of InputMethodAdapter
"jdk/src/windows/classes/sun/awt/windows/WInputMethod.java" does
nothing except calling "disableInputMethod()" from its overridden
"stopListening()", which means that this fix will not change the
logic in Windows implementation.
 2. Mac OS implementation of InputMethodAdapter
"jdk/src/macosx/classes/sun/lwawt/macosx/CInputMethod.java" does not
override "stopListening()" at all and has just a stub implementation
of "disableInputMethod()", thus the fix cannot influence behavior of
InputMethodAdapter on Mac OS.

The following tests were run on Linux and Windows with enabled input
methods, and no negative changes in tests' results for JDK without/with
fix were observed:

 1. Manual/automatic jtreg tests from java/awt/im directory.
 2. Automatic jtreg tests from Focus, keyboard, KeyboardFocusmanager
directories.
 3. JCK tests from "api/java_awt/im" and "api/java_awt/InputMethod".


Thank you,
Anton


On 11/7/2012 10:03 PM, Naoto Sato wrote:

Thank you for trying stopListening() out. Later I figured out that
this method is only used when the input method instance switches the
underlying input method engine from native OS's InputMethodAdapter
instance to pure Java input method, so in this problem case it may not
seem to apply. Let me know your further findings.

Naoto

On 11/7/12 8:11 AM, Anton Litvinov wrote:

Hello Naoto,

Yes, sure, I tried calling "stopListening()" method. But it does not
lead to complete disabling of the input methods and appearance of the
opportunity of entering a text into JPasswordField, when some
composition started in JTextField before switch of focus from the last
one to JPasswordField. Such situation happens, because "resetXIC()" is
not called after "disableInputMethod()" inside "stopListening()" of
"sun.awt.X11InputMethod" for the reason of unset flag "needResetXIC"
after a call to "endComposition()". I think that I need to substitute a
part of the fix calling to "endComposition()" and "disableInputMethod()"
inside "disableNativeIM()" of "sun.awt.im.InputContext" for one call to
"stopListening()". But before providing a next version of the fix for a
review I will have to run regression tests connected with IM on
platforms other than Linux and it will require some time.

Thank you,
Anton

On 11/6/2012 11:21 PM, Naoto Sato wrote:

Hi Anton,

In order for native input methods to not grab the native events, I
would guess that calling InputMethodAdapter.stopListening() would be
the right solution to me. Have you tried considering calling this?

Naoto

On 11/5/12 3:14 AM, Anton Litvinov wrote:

Hello Naoto,

Thank you for the review. A call to "endComposition()" was added to
the
shared code for resolution of another problem which was additionally
observed. The problem consists in the fact that some not completely
composed string inside JTextField can stay in composition state after
the focus is moved from JTextField to JPasswordField. This not
completed
string marked with underscore disappears from JTextField at the moment
when JTextField receives focus again. So I decided to make this string
disappear when a component with disabled input methods, in current
case
JPasswordField, receives focus by a call to "endComposition()" method.
Perhaps, it would be better to remove this call from the fix at all,
because absence of end of text composition during switch of focus
between component with enabled and disabled input methods can be
another
separate issue, would not it? But, on the other hand, since this fix
brings the case with not composed string to a v

Re: [8] Review request for 6789984: JPasswordField can not receive keyboard input

[Naoto Sato]

Looks good to me. Thank you for fixing this IM bug!

Naoto

On 11/13/12 6:54 AM, Anton Litvinov wrote:

Hello Naoto,

Thank you for reviewing this fix and pointing to a directory with Java
input method (IM) implementation. Could you review a new version of the
webrev containing a correction in comments of
"sun.awt.im.InputMethodAdapter.stopListening()". In comparison with
previous webrev the new one has additional changes only in
"InputMethodAdapter.java".

Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.02

The fix was manually tested with Java input methods (IMs) and native IMs
loaded simultaneously on Linux and Windows hosts. "CodePointIM.jar" and
"CityIM.jar" were used as Java IMs. No cases of loosing of ability to
enter text into JPasswordField were observed after switches from Java to
native IMs and vice versa. Also the IMs did loose their functional
capabilities between those switches.

Thank you,
Anton


On 11/13/2012 3:08 AM, Naoto Sato wrote:

The fix looks good. I'd suggest modifying the comment for
sun.awt.im.InputMethodAdapter.stopListening() too, since the method is
now being issued even when Java input method is not active.

Also, please make sure there is no issue on switching the input method
between the input method adapter and a Java input method, such as
CodePointInputMethod which is in the JDK demo directory.

Thanks!
Naoto

On 11/11/12 12:07 PM, Anton Litvinov wrote:

Hello Naoto,

Could you, please, review a modified version of the fix, where a former
duplicating code "endComposition();disableInputMethod()" was substituted
for one call to "stopListening()". Also larger testing of the fix was
done on Linux and Windows machine.

Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.01

I came to a conclusion that substitution of call to
"disableInputMethod()" for "stopListening()" in
"sun.awt.im.InputContext", which is code shared between different
platforms, will not lead to any changes on platforms other than Linux
and Solaris. In order to prove this the following facts are provided:

 1. Windows implementation of InputMethodAdapter
"jdk/src/windows/classes/sun/awt/windows/WInputMethod.java" does
nothing except calling "disableInputMethod()" from its overridden
"stopListening()", which means that this fix will not change the
logic in Windows implementation.
 2. Mac OS implementation of InputMethodAdapter
"jdk/src/macosx/classes/sun/lwawt/macosx/CInputMethod.java" does not
override "stopListening()" at all and has just a stub implementation
of "disableInputMethod()", thus the fix cannot influence behavior of
InputMethodAdapter on Mac OS.

The following tests were run on Linux and Windows with enabled input
methods, and no negative changes in tests' results for JDK without/with
fix were observed:

 1. Manual/automatic jtreg tests from java/awt/im directory.
 2. Automatic jtreg tests from Focus, keyboard, KeyboardFocusmanager
directories.
 3. JCK tests from "api/java_awt/im" and "api/java_awt/InputMethod".


Thank you,
Anton


On 11/7/2012 10:03 PM, Naoto Sato wrote:

Thank you for trying stopListening() out. Later I figured out that
this method is only used when the input method instance switches the
underlying input method engine from native OS's InputMethodAdapter
instance to pure Java input method, so in this problem case it may not
seem to apply. Let me know your further findings.

Naoto

On 11/7/12 8:11 AM, Anton Litvinov wrote:

Hello Naoto,

Yes, sure, I tried calling "stopListening()" method. But it does not
lead to complete disabling of the input methods and appearance of the
opportunity of entering a text into JPasswordField, when some
composition started in JTextField before switch of focus from the last
one to JPasswordField. Such situation happens, because "resetXIC()" is
not called after "disableInputMethod()" inside "stopListening()" of
"sun.awt.X11InputMethod" for the reason of unset flag "needResetXIC"
after a call to "endComposition()". I think that I need to
substitute a
part of the fix calling to "endComposition()" and
"disableInputMethod()"
inside "disableNativeIM()" of "sun.awt.im.InputContext" for one
call to
"stopListening()". But before providing a next version of the fix
for a
review I will have to run regression tests connected with IM on
platforms other than Linux and it will require some time.

Thank you,
Anton

On 11/6/2012 11:21 PM, Naoto Sato wrote:

Hi Anton,

In order for native input methods to not grab the native events, I
would guess that calling InputMethodAdapter.stopListening() would be
the right solution to me. Have you tried considering calling this?

Naoto

On 11/5/12 3:14 AM, Anton Litv

Re: [8] Review request for 6789984: JPasswordField can not receive keyboard input

[Naoto Sato]

Hi Anton,

In order for native input methods to not grab the native events, I would 
guess that calling InputMethodAdapter.stopListening() would be the right 
solution to me. Have you tried considering calling this?


Naoto

On 11/5/12 3:14 AM, Anton Litvinov wrote:

Hello Naoto,

Thank you for the review. A call to "endComposition()" was added to the
shared code for resolution of another problem which was additionally
observed. The problem consists in the fact that some not completely
composed string inside JTextField can stay in composition state after
the focus is moved from JTextField to JPasswordField. This not completed
string marked with underscore disappears from JTextField at the moment
when JTextField receives focus again. So I decided to make this string
disappear when a component with disabled input methods, in current case
JPasswordField, receives focus by a call to "endComposition()" method.
Perhaps, it would be better to remove this call from the fix at all,
because absence of end of text composition during switch of focus
between component with enabled and disabled input methods can be another
separate issue, would not it? But, on the other hand, since this fix
brings the case with not composed string to a view, it should contain
some solution which is specific to Unix platforms.

Also a new comment concerning a root cause of the bug from my view point
and a proposed solution was added to a page of the bug. Since it is not
visible on "http://bugs.sun.com"; yet, it can be seen on Oracle's
internal bug tracking resource.

Thank you,
Anton

On 11/2/2012 9:08 PM, Naoto Sato wrote:

Hi Anton,

What's the reason for adding endComposition() in the shared code?
endComposition() is supposed to end the unfinished composed string
that is currently in composition, and the bug does not mention
anything regarding the composition. Also, it looks like the bug is
localized only to SCIM on Unix platforms, and calling resetXIC() looks
just enough in XIM handling code to me.

Naoto

On 11/2/12 5:43 AM, Anthony Petrov wrote:

Hi Anton,

I'm not an expert in IM code, but generally the changes look good to me.
I'm also CC'ing i18n-dev@ to take a look at this fix.

My only concern is that you're changing shared code here. Did you run
any IM tests on other platforms to make sure no regressions are
introduced?

Also, could you please add a comment to the bug report explaining the
root cause of the issue and how the proposed solution helps resolve it?

--
best regards,
Anthony

On 11/1/2012 8:40 PM, Anton Litvinov wrote:

Hello,

Please review the following fix for a bug.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00

This bug consists in inability of JPasswordField to react on any
keyboard events under certain conditions on Linux OS. The webrev does
not contain any new "jtreg" test, because a particular Linux OS
distribution with additionally installed packages are required for
reproduction of the bug.

Requirements to the environment:
1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux
(OEL) 5.5 x86 64
2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
packages installed on the OS.
3. JDK 8.
4. A simple Java Swing application, where a dialog with both
JTextField and JPasswordField is displayed.

Thank you,
Anton

Re: [8] Review request for 6789984: JPasswordField can not receive keyboard input

[Naoto Sato]

Thank you for trying stopListening() out. Later I figured out that this 
method is only used when the input method instance switches the 
underlying input method engine from native OS's InputMethodAdapter 
instance to pure Java input method, so in this problem case it may not 
seem to apply. Let me know your further findings.


Naoto

On 11/7/12 8:11 AM, Anton Litvinov wrote:

Hello Naoto,

Yes, sure, I tried calling "stopListening()" method. But it does not
lead to complete disabling of the input methods and appearance of the
opportunity of entering a text into JPasswordField, when some
composition started in JTextField before switch of focus from the last
one to JPasswordField. Such situation happens, because "resetXIC()" is
not called after "disableInputMethod()" inside "stopListening()" of
"sun.awt.X11InputMethod" for the reason of unset flag "needResetXIC"
after a call to "endComposition()". I think that I need to substitute a
part of the fix calling to "endComposition()" and "disableInputMethod()"
inside "disableNativeIM()" of "sun.awt.im.InputContext" for one call to
"stopListening()". But before providing a next version of the fix for a
review I will have to run regression tests connected with IM on
platforms other than Linux and it will require some time.

Thank you,
Anton

On 11/6/2012 11:21 PM, Naoto Sato wrote:

Hi Anton,

In order for native input methods to not grab the native events, I
would guess that calling InputMethodAdapter.stopListening() would be
the right solution to me. Have you tried considering calling this?

Naoto

On 11/5/12 3:14 AM, Anton Litvinov wrote:

Hello Naoto,

Thank you for the review. A call to "endComposition()" was added to the
shared code for resolution of another problem which was additionally
observed. The problem consists in the fact that some not completely
composed string inside JTextField can stay in composition state after
the focus is moved from JTextField to JPasswordField. This not completed
string marked with underscore disappears from JTextField at the moment
when JTextField receives focus again. So I decided to make this string
disappear when a component with disabled input methods, in current case
JPasswordField, receives focus by a call to "endComposition()" method.
Perhaps, it would be better to remove this call from the fix at all,
because absence of end of text composition during switch of focus
between component with enabled and disabled input methods can be another
separate issue, would not it? But, on the other hand, since this fix
brings the case with not composed string to a view, it should contain
some solution which is specific to Unix platforms.

Also a new comment concerning a root cause of the bug from my view point
and a proposed solution was added to a page of the bug. Since it is not
visible on "http://bugs.sun.com"; yet, it can be seen on Oracle's
internal bug tracking resource.

Thank you,
Anton

On 11/2/2012 9:08 PM, Naoto Sato wrote:

Hi Anton,

What's the reason for adding endComposition() in the shared code?
endComposition() is supposed to end the unfinished composed string
that is currently in composition, and the bug does not mention
anything regarding the composition. Also, it looks like the bug is
localized only to SCIM on Unix platforms, and calling resetXIC() looks
just enough in XIM handling code to me.

Naoto

On 11/2/12 5:43 AM, Anthony Petrov wrote:

Hi Anton,

I'm not an expert in IM code, but generally the changes look good
to me.
I'm also CC'ing i18n-dev@ to take a look at this fix.

My only concern is that you're changing shared code here. Did you run
any IM tests on other platforms to make sure no regressions are
introduced?

Also, could you please add a comment to the bug report explaining the
root cause of the issue and how the proposed solution helps resolve
it?

--
best regards,
Anthony

On 11/1/2012 8:40 PM, Anton Litvinov wrote:

Hello,

Please review the following fix for a bug.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00

This bug consists in inability of JPasswordField to react on any
keyboard events under certain conditions on Linux OS. The webrev does
not contain any new "jtreg" test, because a particular Linux OS
distribution with additionally installed packages are required for
reproduction of the bug.

Requirements to the environment:
1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux
(OEL) 5.5 x86 64
2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
packages installed on the OS.
3. JDK 8.
4. A simple Java Swing application, where a dialog with both
JTextField and JPasswordField is displayed.

Thank you,
Anton

Re: [8] Review request for 6789984: JPasswordField can not receive keyboard input

[Naoto Sato]

Hi Anton,

What's the reason for adding endComposition() in the shared code? 
endComposition() is supposed to end the unfinished composed string that 
is currently in composition, and the bug does not mention anything 
regarding the composition. Also, it looks like the bug is localized only 
to SCIM on Unix platforms, and calling resetXIC() looks just enough in 
XIM handling code to me.


Naoto

On 11/2/12 5:43 AM, Anthony Petrov wrote:

Hi Anton,

I'm not an expert in IM code, but generally the changes look good to me.
I'm also CC'ing i18n-dev@ to take a look at this fix.

My only concern is that you're changing shared code here. Did you run
any IM tests on other platforms to make sure no regressions are introduced?

Also, could you please add a comment to the bug report explaining the
root cause of the issue and how the proposed solution helps resolve it?

--
best regards,
Anthony

On 11/1/2012 8:40 PM, Anton Litvinov wrote:

Hello,

Please review the following fix for a bug.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00

This bug consists in inability of JPasswordField to react on any
keyboard events under certain conditions on Linux OS. The webrev does
not contain any new "jtreg" test, because a particular Linux OS
distribution with additionally installed packages are required for
reproduction of the bug.

Requirements to the environment:
1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux
(OEL) 5.5 x86 64
2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
packages installed on the OS.
3. JDK 8.
4. A simple Java Swing application, where a dialog with both
JTextField and JPasswordField is displayed.

Thank you,
Anton

Re: Add some missing key maps

[Naoto Sato]

The patch is changing the code to always convert VK_KANA_LOCK to 
XK_Kana_Lock keysym. Does this work with Solaris? Looks like there are 
some piece of code that specifically handles KANA_LOCK.


Naoto

On 6/5/12 9:02 AM, Anthony Petrov wrote:

Hi Charles,

I'm not an expert in keyboard-related code, but the code changes look
good to me.

I think I18n team might want to take a look at the fix as well, so I'm
CC'ing the i18n-dev@ mailing list.

--
best regards,
Anthony

On 6/5/2012 7:19 AM, Charles Lee wrote:

Hi awt-devs,

There are some key map missing in the Japanese keyboard, for example:
XK_Eisu_Shift, XK_Romaji, etc.

I'd like to propose a patch @
http://cr.openjdk.java.net/~littlee/7174233/webrev.00/


The patch is mainly about add these missing maps according to their
means.

Would anyone help to take a look at it?

--
Yours Charles

Re: Add some missing key maps

[Naoto Sato]

I double checked your patch and confirmed that the table lookup comes 
after those KANA specific handling, so it looks ok to me.


Naoto

On 6/5/12 8:13 PM, Charles Lee wrote:

Thank you Naoto. Thank you Anthony.

I do not see the problem. Would some solaris guys take a look on this
issue?

On 06/06/2012 01:56 AM, Naoto Sato wrote:

The patch is changing the code to always convert VK_KANA_LOCK to
XK_Kana_Lock keysym. Does this work with Solaris? Looks like there are
some piece of code that specifically handles KANA_LOCK.

Naoto

On 6/5/12 9:02 AM, Anthony Petrov wrote:

Hi Charles,

I'm not an expert in keyboard-related code, but the code changes look
good to me.

I think I18n team might want to take a look at the fix as well, so I'm
CC'ing the i18n-dev@ mailing list.

--
best regards,
Anthony

On 6/5/2012 7:19 AM, Charles Lee wrote:

Hi awt-devs,

There are some key map missing in the Japanese keyboard, for example:
XK_Eisu_Shift, XK_Romaji, etc.

I'd like to propose a patch @
http://cr.openjdk.java.net/~littlee/7174233/webrev.00/
<http://cr.openjdk.java.net/%7Elittlee/7174233/webrev.00/>

The patch is mainly about add these missing maps according to their
means.

Would anyone help to take a look at it?

--
Yours Charles