为什么CDI bean不支持最终方法

Question

我只是在GlassFish服务器下引发了臭名昭著的JavaEE CDI错误：

org.glassfish.deployment.common.DeploymentException: CDI deployment failure:Exception List with 2 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001437 Normal scoped bean class ASController is not proxyable because the type is final or it contains a final method public final void ASController.selectPath(org.primefaces.event.NodeSelectEvent) - Managed Bean [class ASController] with qualifiers [@Default @Any @Named].

该错误非常明显，因为他不喜欢CDI bean中的最终方法，但是我不明白为什么。

在此链接

http://docs.jboss.org/weld/reference/1.1.0.Final/zh-
CN/html_single/#d0e1429

他们解释说，这与序列化有关，但我看不出为什么用final方法序列化一个类比使用非final方法序列化一个类更难。

Answer 1

好了，有几种方法可以实现代理对象。但是，由于您希望代理与被代理bean具有“相同”类型，因此您必须使用继承（或您随后可以实现的需求接口，但这不是每个POJO都可以是一个bean的方法）
CDI）。

也就是说，它们从您要注入的类内部扩展，围绕该类生成一些代理代码，然后为您提供该子类。

然后，该代理将处理所有魔术，以确保您始终有一个适合您上下文的bean（并且该bean的所有成员变量bean均指向正确的bean）。

因此，您实际上并没有收到要注入的bean的类型，而是该bean的代理子类。这对于最终方法和类以及私有构造函数而言效果不佳。

如果该类不是final，则代理可以扩展该类，但是它不能轻易覆盖您的final方法。但是，这可能是需要的（例如，如果您的bean已序列化，则代理需要对其进行反序列化）。

有更复杂的方法可以解决。可以通过通过代理操作类的字节码来注入此功能（例如，删除最终修饰符，注入默认构造函数等），甚至可以将其与继承混合使用，但这还没有实现（和同样对支持多个JVM实现也很重要）。

在链接的资源中，有一条注释表明已计划在将来的发行版中使用：

注意

未来的Weld版本可能会使用非便携式JVM
API支持针对此限制的非标准解决方法：Sun，IcedTea，Mac：Unsafe.allocateInstance（）（最高效）IBM，JRockit：ReflectionFactory.newConstructorForSerialization（）

但是我们还没有实现这个目标。