Hello, I would like to create a fix for https://bugs.openjdk.org/browse/JDK-8307942 and contribute it. I'm having some issues while considering a fix, and I'd like to ask for your advice.
This issue is caused by the fact that `TranslateMessage`, used in the Windows message loop, and `ToUnicodeEx`, used by the EDT in a separate thread, share a static kernel buffer internally and overwrite each other’s data. If TranslateMessage and ToUnicodeEx are executed in the correct order for the same key event, no problems occur. However, in cases of high-speed input?such as from a barcode scanner?or when a KeyListener requires time-consuming processing, the order of inputs like Alt+NumPad or dead keys may be disrupted, causing the kernel buffer to be corrupted and resulting in the generation of incorrect WM_CHAR messages. Therefore, to resolve this issue, we must ensure that ToUnicodeEx does not conflict with TranslateMessage and corrupt the kernel buffer. When I asked Microsoft on MSDN how to avoid corrupting the kernel buffer, they suggested using the wFlags option with ToUnicodeEx. However, when I tried making the fix and running the program, it didn’t behave as expected and ended up corrupting the kernel buffer just as it had before the fix. As an alternative, Microsoft suggested creating a conversion table in advance to map keys to characters. However, to ensure compatibility using this method, it is necessary to create a table structure that supports keyboard layouts for all languages supported by Windows and guarantee that it works properly. That's a very disruptive change, and I find it unacceptable. I would like to hear the opinions of the experts in the core-libs community on how this issue should be resolved. Thank you. Masanori Yano
