> On 26 Mar 2019, at 07:54, Peter Levart <peter.lev...@gmail.com> wrote: > > Hi Seth, > > I think you stumbled on a "defect" of Java Serialization mechanism. Namely, > the inability for it to correctly deserialize object graphs containing a > cycle when an object in such cycle uses the "readResolve()" special method to > replace the deserialized object with a replacement object. SerializedLambda > is a class with instances that are 1st deserialized from stream then > "replaced" with real lambda objects via the "readResolve()" method which > constructs and returns the "real" lambda object. The deserialized > SerializedLambda object is nevertheless attempted to be (temporarily) > assigned to the field that would hold the final lambda object, which fails as > the filed is of different type than SerializedLambda (or supertype). > > You can check my claims by changing the type of the field holding the lambda > to java.lang.Object and see if it works... (It should if my memory serves me > well :-) > > This is a known defect of Java serialization and is not specific to > serialized lambda.
Correct. Cycles in the object graph can be problematic when mixed with Serializable classes that have a readResolve method or the follow the Serialization Proxy Pattern. The Immutable Collection implementations are another such example. I see David pointed to some specific unresolved issues relating to Serializable lambdas. I haven't looked into them. -Chris.
