LitnhJacuzzi

@kostaskougios Yes, you can't directly call that method in Unsafe. I wrote a method to solve it: ```java private static Unsafe hackUnsafe() { try { Field field = Unsafe.class.getDeclaredField("theUnsafe"); field.setAccessible(true);...

Note that the efficiency of the Unsafe.allocateInstance() method is about 2000 times that of Objenesis. But the instantiated objects has not gone any initialization, and the fields in these objects...

The stream read operation is fundamentally based on the file handler which gets by the long field handle in class FileDescriptor. It means different streams have different file handlers(even if...

没关系，理解。我之前开了一个临时仓库[IMBlocker Update](https://github.com/LitnhJacuzzi/IMBlocker-Update)来暂时填补这个模组更新的空白期，原版/REI/EMI我都使用了新的实现方式并测试过全部正常工作。不过存放这个项目源码的电脑暂时不在我身边没法发PR，目前你只能通过反编译的方式迁移更改的内容，抱歉。 焦点监听确实会与原来的实现产生一定的冲突，新的实现中已经禁用了`onCharTyped`监听的方式（因为它不是决定输入法状态的关键，直接消除它可能带来的副作用为好），改动的内容可能较多。一个比较关键的点是截至我最后一次构建时setFocused方法都无法正常映射混淆名，需要手动更改jar中的client-fabric-refmap.json文件，具体内容直接复制我发布的版本中的json文件即可。 我由于是独立桌面环境开发者所以对操作系统GUI接口层的设计比较熟悉，新的实现方式可能有些地方涉及一些比较深层的GUI设计规范，有疑问的话随时提出即可。

> 按理说我是按照GPL开源的，所以也希望你能把你的代码传到仓库上去。 等我拿到存放源码的电脑就可以传，大概还要一周左右的时间。 GUI设计规范中，“焦点是一个GUI系统中用于定向键盘输入的关键属性，在一个标准的GUI系统中，如果此系统被操作系统赋予了焦点，那么其中有且只有一个焦点组件，在没有全局键盘监听的情况下，键盘输入最终只会在这一个组件上产生效果“，之前有提到过这一点。引出这个规范的目的是说明输入法状态最关键的决定因素——当前可以接收键盘输入的组件，是如何被定位的。虽然MC的焦点系统有些另类（这个后面会解释一下），但任何最终效果符合通用GUI系统规定的GUI都必须以某种方式遵循这一规范，MC的GUI系统也不例外，因此遵照这个规范使用焦点监听来决定输入法状态是实现imblocker的最佳方式。 一般成熟的GUI框架中都会有一个全局变量来存储当前持有焦点的组件，在键盘输入由操作系统传入GUI框架时可以很容易地将其重定向到持有焦点的组件。不过MC的GUI框架并没有遵循这个普遍的实现方式，而是自上而下遍历组件树中的每个组件寻找获得了焦点的组件，在这个组件处理完键盘输入（也就是`onCharTyped`返回）后结束遍历，这是一种效率很低的做法，但是不影响”只有获得了焦点的组件才能处理键盘输入“这一要求——除了一种例外：类似于告示牌编辑界面显示时键盘输入会定向到告示牌里而不是焦点组件，目前我只发现MC的GUI实现在这类Screen下不太守规矩，这种情况直接用白名单处理就行。因此大多数情况下我们存储的焦点组件总是当前接收键盘输入的组件。 还有一个值得注意的事实是MC的GUI系统没有逻辑Z轴的处理系统，只有渲染Z轴，也就是说当组件重叠显示的时候它们会同时接收一个鼠标事件（在一般的GUI系统中只有最上面的组件会接收鼠标事件），因此监听鼠标事件来决定输入法状态可能会导致意料之外的结果。

可以的话建议逐渐除去与焦点监听无关的实现，因为据我的观察不少现有实现依赖的API随原版和要适配的mod更新变化比较多，维护起来不太方便，如果只用焦点监听的话可以同时适配1.19.4和1.20所有的版本（1.18或许也行，不过我没测试过）

@reserveword 已提交PR

可以的。 你可能指的是依赖项版本的改动，那些是当时为了测试兼容性做的更改，可以不用理会，所有依赖项的版本都是兼容的。

是的，至少目前为止我个人使用没有发现问题。删除冗余规则的主要目的是增强模组兼容性和可维护性，在只有焦点监听的情况下模组从1.20.4更新到1.21不用改动任何内容也可以保证完整的兼容性。

[IMBlocker-5.0.0-beta-1.19.4+.zip](https://github.com/user-attachments/files/18392430/IMBlocker-5.0.0-beta-1.19.4%2B.zip) 试试这个版本能否正常工作（链接#65）