我料到人们会对此提出疑问... 那么为什么我们决定废弃Hibernate中的CGLIB支持呢？首先，我想指出Hibernate和CGLIB在合作方面有着非常悠久的历史（以及大部分良好的历史）。这并不是对任何CGLIB开发者的指控。他们是好人，正如我上面所说，Hibernate和CGLIB多年来一直合作得很好。
简单的事实是，CGLIB的开发已经基本停止。这是常有的事。开发者由于各种原因（这些原因属于他们自己）转向了新的优先事项。
大约4年前，我注意到CGLIB的开发甚至已经放缓，这引起我的注意是在关于HHH-2222的JIRA问题。JIRA问题本身描述的问题并不重要；重要的是，所谓的“修复”仅仅是使用更新的ASM库发布的CGLIB 2.2版本。这个2.2版本发布已经超过一年。
最近我们遇到了CGLIB的一些问题，包括与签名jar有关的问题以及它对注解实体字节码增强的处理。Hibernate团队已经提交了补丁（尽我们所能），但我们发现这些问题后，甚至没有收到任何回复。
所以这实际上归结为一个决定，我们是否希望为Hibernate维护一个CGLIB分叉以修复所需的问题。但这不是我们的核心专长，我们已经与另一个优秀的字节码库Javassist集成了。因此，我认为是时候继续前进了。
BytecodeProvider作为一个SPI，将保持完整，因此用户可以自由继续使用CGLIB作为Hibernate的字节码提供者。我们只是不再维护集成。
