针对你遇到的问题，核心原因主要集中在AWT与Linux输入法框架的集成限制、Locale匹配逻辑差异这几方面：

1. AWT InputContext与IBus的集成缺陷 #

Linux环境下，AWT的InputContext实现对IBus框架的支持并不完善，尤其是X11会话中。selectInputMethod(Locale)方法的设计基于Windows平台的输入法-Locale绑定逻辑，但IBus的输入法管理是通过引擎名称而非直接绑定Locale来工作的。AWT无法正确将传入的Locale映射到对应的IBus输入法引擎（比如ibus-mozc），导致切换请求被忽略，始终 fallback 到系统默认的en_US Locale。

2. Locale匹配的实际偏差 #

ibus-mozc在系统中的注册Locale可能并非严格对应Locale.JAPAN（即ja_JP），部分配置下mozc可能使用其他Locale标识，或者系统全局Locale优先级高于AWT的请求。你可以通过ibus list-engine命令查看mozc的实际注册信息，确认其关联的Locale是否与代码中指定的一致。

3. OpenJDK的特定实现限制 #

虽然你使用的是OpenJDK 21，但X11环境下OpenJDK的AWT模块对IBus的切换逻辑存在历史bug，无法正确枚举或激活非系统默认的输入法。这种情况在多个OpenJDK版本中都有出现，尤其是当系统同时存在多语种输入法时。

验证与临时解决方向 #

• 先通过命令行测试IBus切换：执行ibus engine mozc，如果能成功切换到日语输入法，说明问题出在AWT的调用层，可以考虑通过调用系统命令（如Runtime.getRuntime().exec("ibus engine mozc")）替代InputContext的方法。
• 检查系统Locale：运行locale -a确认ja_JP.UTF-8已生成，若没有则执行locale-gen ja_JP.UTF-8生成对应的Locale文件。
• 尝试切换到Oracle JDK：部分场景下Oracle JDK对Linux输入法的集成支持优于OpenJDK，可以测试是否能正常切换。

内容的提问来源于stack exchange，提问作者norman