Java 转换:Java 11 抛出 LambdaConversionException 而 1.8 没有
Java Casting: Java 11 throws LambdaConversionException while 1.8 does not
以下代码在 Java 1.8 VM 中运行良好,但在 Java 11 VM 中执行时会生成 LambdaConversionException
。区别在哪里,为什么会这样?
代码:
public void addSomeListener(Component comp){
if(comp instanceof HasValue) {
((HasValue<?,?>) comp).addValueChangeListener(evt -> {
//do sth with evt
});
}
}
异常(仅限 V11):
Caused by: java.lang.invoke.LambdaConversionException: Type mismatch
for instantiated parameter 0: class java.lang.Object is not a subtype
of interface com.vaadin.flow.component.HasValue$ValueChangeEvent
at java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.checkDescriptor(AbstractValidatingLambdaMetafactory.java:308)
at java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:294)
at java.base/java.lang.invoke.LambdaMetafactory.altMetafactory(LambdaMetafactory.java:503)
at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:138)
... 73 more
解决方法:
ValueChangeListener<ValueChangeEvent<?>> listener = evt -> {
// do sth with evt
};
((HasValue<?,?>) comp).addValueChangeListener(listener);
系统:
OS: Windows 10
IDE:日食 2018-12 (4.10.0)
Java(编译):ecj
Java(网络服务器):JDK 11.0.2
网络服务器:Wildfly 15
TL;DR Eclipse 编译器为 lambda 实例生成了一个根据规范无效的方法签名。由于在 JDK 9 中添加了额外的类型检查代码以更好地执行规范,不正确的签名现在在 运行 on Java 11 时导致异常。
已使用 Eclipse 2019-03 以及此代码进行验证:
public class Main {
public static void main(String[] args) {
getHasValue().addValueChangeListener(evt -> {});
}
public static HasValue<?, ?> getHasValue() {
return null;
}
}
interface HasValue<E extends HasValue.ValueChangeEvent<V>,V> {
public static interface ValueChangeEvent<V> {}
public static interface ValueChangeListener<E extends HasValue.ValueChangeEvent<?>> {
void valueChanged(E event);
}
void addValueChangeListener(HasValue.ValueChangeListener<? super E> listener);
}
即使使用 null
作为接收器,代码在引导时也会失败并出现相同的错误。
使用javap -v Main
可以看出问题出在哪里。我在 BoostrapMethods table:
中看到了这个
BootstrapMethods:
0: #48 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
Method arguments:
#50 (Lmain/HasValue$ValueChangeEvent;)V
#53 REF_invokeStatic main/Main.lambda[=11=]:(Ljava/lang/Object;)V
#54 (Ljava/lang/Object;)V
请注意,最后一个参数(常数 #54)是 (Ljava/lang/Object;)V
,而 javac
生成 (Lmain/HasValue$ValueChangeEvent;)V
。即 Eclipse 想要用于 lambda 的方法签名与 javac
想要使用的不同。
如果想要的方法签名是目标方法的擦除(看起来是这样),那么正确的方法签名确实是(Lmain/HasValue$ValueChangeEvent;)V
,因为那是目标方法的擦除,也就是:
void valueChanged(E event);
其中 E
是 E extends HasValue.ValueChangeEvent<?>
,因此将被删除为 HasValue.ValueChangeEvent
。
问题似乎出在 ECJ 上,并且似乎已通过 JDK-8173587 (revision) (Unfortunately this seems to be a private ticket.) which adds extra type checks to verify that the SAM method type is actually compatible with the instantiate method type. According to the documentation of LambdaMetafactory::metafactory
实例化的方法类型必须相同,或者 SAM 方法类型的特化:
instantiatedMethodType - The signature and return type that should be enforced dynamically at invocation time. This may be the same as samMethodType, or may be a specialization of it.
ECJ生成的方法类型显然不是,所以最终抛出异常。 (不过,公平地说,在这种情况下,我在任何地方都看不到构成 "specialization" 的定义)。我已经在此处的 Eclipse bugzilla 上报告了这一点:https://bugs.eclipse.org/bugs/show_bug.cgi?id=546161
我猜这个更改是在 JDK 9 的某处进行的,因为源代码在那时已经是模块化的,并且修订日期相当早(2017 年 2 月)。
由于 javac
生成了正确的方法签名,您可以暂时切换到它作为解决方法。
以下代码在 Java 1.8 VM 中运行良好,但在 Java 11 VM 中执行时会生成 LambdaConversionException
。区别在哪里,为什么会这样?
代码:
public void addSomeListener(Component comp){
if(comp instanceof HasValue) {
((HasValue<?,?>) comp).addValueChangeListener(evt -> {
//do sth with evt
});
}
}
异常(仅限 V11):
Caused by: java.lang.invoke.LambdaConversionException: Type mismatch
for instantiated parameter 0: class java.lang.Object is not a subtype
of interface com.vaadin.flow.component.HasValue$ValueChangeEvent
at java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.checkDescriptor(AbstractValidatingLambdaMetafactory.java:308)
at java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:294)
at java.base/java.lang.invoke.LambdaMetafactory.altMetafactory(LambdaMetafactory.java:503)
at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:138)
... 73 more
解决方法:
ValueChangeListener<ValueChangeEvent<?>> listener = evt -> {
// do sth with evt
};
((HasValue<?,?>) comp).addValueChangeListener(listener);
系统:
OS: Windows 10
IDE:日食 2018-12 (4.10.0)
Java(编译):ecj
Java(网络服务器):JDK 11.0.2
网络服务器:Wildfly 15
TL;DR Eclipse 编译器为 lambda 实例生成了一个根据规范无效的方法签名。由于在 JDK 9 中添加了额外的类型检查代码以更好地执行规范,不正确的签名现在在 运行 on Java 11 时导致异常。
已使用 Eclipse 2019-03 以及此代码进行验证:
public class Main {
public static void main(String[] args) {
getHasValue().addValueChangeListener(evt -> {});
}
public static HasValue<?, ?> getHasValue() {
return null;
}
}
interface HasValue<E extends HasValue.ValueChangeEvent<V>,V> {
public static interface ValueChangeEvent<V> {}
public static interface ValueChangeListener<E extends HasValue.ValueChangeEvent<?>> {
void valueChanged(E event);
}
void addValueChangeListener(HasValue.ValueChangeListener<? super E> listener);
}
即使使用 null
作为接收器,代码在引导时也会失败并出现相同的错误。
使用javap -v Main
可以看出问题出在哪里。我在 BoostrapMethods table:
BootstrapMethods:
0: #48 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
Method arguments:
#50 (Lmain/HasValue$ValueChangeEvent;)V
#53 REF_invokeStatic main/Main.lambda[=11=]:(Ljava/lang/Object;)V
#54 (Ljava/lang/Object;)V
请注意,最后一个参数(常数 #54)是 (Ljava/lang/Object;)V
,而 javac
生成 (Lmain/HasValue$ValueChangeEvent;)V
。即 Eclipse 想要用于 lambda 的方法签名与 javac
想要使用的不同。
如果想要的方法签名是目标方法的擦除(看起来是这样),那么正确的方法签名确实是(Lmain/HasValue$ValueChangeEvent;)V
,因为那是目标方法的擦除,也就是:
void valueChanged(E event);
其中 E
是 E extends HasValue.ValueChangeEvent<?>
,因此将被删除为 HasValue.ValueChangeEvent
。
问题似乎出在 ECJ 上,并且似乎已通过 JDK-8173587 (revision) (Unfortunately this seems to be a private ticket.) which adds extra type checks to verify that the SAM method type is actually compatible with the instantiate method type. According to the documentation of LambdaMetafactory::metafactory
实例化的方法类型必须相同,或者 SAM 方法类型的特化:
instantiatedMethodType - The signature and return type that should be enforced dynamically at invocation time. This may be the same as samMethodType, or may be a specialization of it.
ECJ生成的方法类型显然不是,所以最终抛出异常。 (不过,公平地说,在这种情况下,我在任何地方都看不到构成 "specialization" 的定义)。我已经在此处的 Eclipse bugzilla 上报告了这一点:https://bugs.eclipse.org/bugs/show_bug.cgi?id=546161
我猜这个更改是在 JDK 9 的某处进行的,因为源代码在那时已经是模块化的,并且修订日期相当早(2017 年 2 月)。
由于 javac
生成了正确的方法签名,您可以暂时切换到它作为解决方法。