JavaConstant.Dynamic.ofInvocation() 中的类型可分配性是否过于严格?
Is type assignability too strict in JavaConstant.Dynamic.ofInvocation()?
我读过 Rafael's article,现在正在用 JavaConstant.Dynamic
做非常糟糕的事情。大多数情况下,我对它的工作原理有所了解。
作为这些可怕实验的一部分,我正在将一个非常量数组变成一个 JavaConstant
数组。然后我调用 JavaConstant.Dynamic.ofInvocation(SOME_METHOD_THAT_ACCEPTS_A_VARARGS_OF_THINGS, javaConstantsArray)
.
所以,例如,像这样的东西:
static final JavaConstant toJavaConstant(final Glorp[] glorps) {
final JavaConstant[] javaConstants = new JavaConstant[glorps.length];
for (int i = 0; i < javaConstants.length; i++) {
javaConstants[i] = toJavaConstant(glorps[i]); // another version of this method that works on scalars
}
return JavaConstant.Dynamic.ofInvocation(SOME_METHOD_THAT_ACCEPTS_A_VARARGS_OF_THINGS, javaConstants);
}
ByteBuddy 在 ofInvocation
调用中告诉我,我传递的可变参数数组中的 JavaConstant
之一无法分配给 SOME_METHOD_THAT_ACCEPTS_A_VARARGS_OF_THINGS
的参数类型.我可以理解这一点,因为严格来说,可变 arity 方法接受数组作为其最后一个参数,而 JavaConstant
不是数组。但是考虑到 SOME_METHOD_THAT_ACCEPTS_A_VARARGS_OF_THINGS
最终通过 MethodHandle
机制及其所有参数适应和传播技巧得到解决,我想知道:this proactive assignability check 是不是“太多了”? ByteBuddy 是否应该考虑 bootstrap 方法的可变参数性质?有没有其他方法可以创建数组或任意数量的标量常量列表作为常量本身?
是的,这是一个错误,将在 Byte Buddy 1.10.18 中修复。感谢补丁!
我读过 Rafael's article,现在正在用 JavaConstant.Dynamic
做非常糟糕的事情。大多数情况下,我对它的工作原理有所了解。
作为这些可怕实验的一部分,我正在将一个非常量数组变成一个 JavaConstant
数组。然后我调用 JavaConstant.Dynamic.ofInvocation(SOME_METHOD_THAT_ACCEPTS_A_VARARGS_OF_THINGS, javaConstantsArray)
.
所以,例如,像这样的东西:
static final JavaConstant toJavaConstant(final Glorp[] glorps) {
final JavaConstant[] javaConstants = new JavaConstant[glorps.length];
for (int i = 0; i < javaConstants.length; i++) {
javaConstants[i] = toJavaConstant(glorps[i]); // another version of this method that works on scalars
}
return JavaConstant.Dynamic.ofInvocation(SOME_METHOD_THAT_ACCEPTS_A_VARARGS_OF_THINGS, javaConstants);
}
ByteBuddy 在 ofInvocation
调用中告诉我,我传递的可变参数数组中的 JavaConstant
之一无法分配给 SOME_METHOD_THAT_ACCEPTS_A_VARARGS_OF_THINGS
的参数类型.我可以理解这一点,因为严格来说,可变 arity 方法接受数组作为其最后一个参数,而 JavaConstant
不是数组。但是考虑到 SOME_METHOD_THAT_ACCEPTS_A_VARARGS_OF_THINGS
最终通过 MethodHandle
机制及其所有参数适应和传播技巧得到解决,我想知道:this proactive assignability check 是不是“太多了”? ByteBuddy 是否应该考虑 bootstrap 方法的可变参数性质?有没有其他方法可以创建数组或任意数量的标量常量列表作为常量本身?
是的,这是一个错误,将在 Byte Buddy 1.10.18 中修复。感谢补丁!