java - 读取具有过时接口(interface)的序列化 lambda

Question

曾几何时，有人注意到第三方库有以下内容:

public interface SerializableFunction<I, O> implements Function<I, O>, Serializable {
}

他们用 Serializable 编写了一些代码类(称之为 Q )，其字段类型为 SerializableFunction<X,Y>对于某些 X 和 Y。该字段始终分配给 lambda .

class Q implements Serializable {
    SerializableFunction<X,Y> lfield;
}

不幸的是，该库有一个不友好的许可证，我们需要停止使用它。有没有办法为Q创建一个readObject方法可以读取旧数据吗？或者除了创建新数据别无选择？

class Q阅读时可用。但是，它使用不同的 SerializableFunction接口(interface) - 不同之处仅在于它位于不同的包中。

早期迹象表明，没有办法解决这个问题:基本的异常(exception)是 IllegalArgumentException阅读lambda 。我看不出有什么方法可以进入这个过程并避免它，但也许我错过了一些东西。

Answer 1

通常，序列化机制非常强大。如果您声明相同 serialVersionUID在您的类中，正如流类描述符所期望的那样，序列化实现将忽略缺失的字段，并将流中不存在的新字段保留为其默认值。

您甚至可以实现 readObject用于初始化新字段或提供重构字段的翻译的方法，例如

private void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {
    ObjectInputStream.GetField fields = ois.readFields();
    this.foo = (String)fields.get("oldNameOfFoo", null);
}

但是，有一个问题:现在不存在的字段引用的对象在删除之前仍会被反序列化，从而将任何相关问题传播给调用者。因为我们无法像 readObject 这样注入(inject)翻译代码方法进入提供的 JRE SerializedLambda表示，没有太多选项可以捕获序列化 lambda 表达式的定义类的缺失。

无论哪种情况，我们都需要控制 ObjectInputStream创建。如果我们已经掌握了它，首先我们创建一个替代品 SerializedLambda类，它允许我们自定义流程，即将旧的功能接口(interface)重定向到新的功能接口(interface):

public final class MySerializedLambda implements Serializable {
    private final Class<?> capturingClass;
    private final String functionalInterfaceClass;
    private final String functionalInterfaceMethodName;
    private final String functionalInterfaceMethodSignature;
    private final String implClass;
    private final String implMethodName;
    private final String implMethodSignature;
    private final int implMethodKind;
    private final String instantiatedMethodType;
    private final Object[] capturedArgs;

    private MySerializedLambda() {
        throw new UnsupportedOperationException();
    }

    private Object readResolve() throws ReflectiveOperationException {
        String funcInterfaceClass = this.functionalInterfaceClass;
        if(funcInterfaceClass.equals("package/to/old/SerializableFunction")) {
            funcInterfaceClass="package/to/new/SerializableFunction";
        }
        SerializedLambda serializedLambda = new SerializedLambda(capturingClass,
            funcInterfaceClass, functionalInterfaceMethodName,
            functionalInterfaceMethodSignature, implMethodKind, implClass, implMethodName,
            implMethodSignature, instantiatedMethodType, capturedArgs);
        Method m = capturingClass
                  .getDeclaredMethod("$deserializeLambda$", SerializedLambda.class);
        m.setAccessible(true);
        return m.invoke(null, serializedLambda);
    }
}

它与原始 SerializedLambda 具有完全相同的字段类，以便我们可以阅读它们，然后追溯什么 SerializedLambda会做readResolve()步骤，但替换功能接口(interface)。

要使用此类，我们需要 ObjectInputStream 的子类:

try(FileInputStream os=new FileInputStream(serialized);
    ObjectInputStream oos=new ObjectInputStream(os) {
        @Override
        protected ObjectStreamClass readClassDescriptor()
                                    throws IOException, ClassNotFoundException {
            final ObjectStreamClass d = super.readClassDescriptor();
            if(d.getName().equals("java.lang.invoke.SerializedLambda")) {
                return ObjectStreamClass.lookup(MySerializedLambda.class);
            }
            return d;
        }
    }) {
    Q q = (Q)oos.readObject();
}

readClassDescriptor()负责验证流类与运行时类的兼容性，因此如果我们之后重定向结果，则会出现不同的 name/package/serialVersionUID没有影响。
不幸的是，SerializedLambda内的功能接口(interface)实例表示为 String ，所以我们不能以同样的方式重定向它......
请注意，接口(interface)的字符串表示使用 JVM 内部语法，即 /而不是.用于包和类分离和 $对于内部类。

相当hacky，但恐怕没有更好的解决方案。

<小时/>

请注意，由于依赖于编译器生成的保存 lambda 主体的方法，序列化 lambda 表达式始终很脆弱。如果您使用使用相同编译器编译的其他未更改的类，则上述解决方案有效，以便函数签名匹配并且合成方法恰好以与以前完全相同的形式出现。