Hi, On Thu, May 1, 2025 at 9:22 AM Emond Papegaaij <emond.papega...@gmail.com> wrote:
> Hi, > > In our application we've also had these issues. As we do have quite a > comprehensive test suite, I tried to detect these issues in tests, but I > was unable to create a reliable way of detecting them. It seems that it's > not always related to the actual lambda being serialized, but the entry > point of the deserialization of that lambda. Many of the issues we could > only reproduce after reloading a page several times. So we just gave up and > make sure we do not use lambda's in some area's. Somehow, certain classes > in our application are way more sensitive than others to these problems. > > We are not 100% certain we are discovering all cases via our tests either. But it helped so far. We started doing this half a year ago and a new version of our product will be out soon... We will see how things go in production and how effective what we do is. > Best regards, > Emond > > Op do 1 mei 2025 om 15:54 schreef Ernesto Reinaldo Barreiro < > reier...@gmail.com>: > > > Hi, > > > > We had also problems and one colleague of mine found out they are all > > related to > > > > https://bugs.openjdk.org/browse/JDK-8024931 > > > > We hunted down all of those. Additionally, we have a "special mode" to > run > > our application where we report all serialization problems into some > > separated log file and we run our selenium tests against such instances > > periodically. Thus, we have an early warning system telling us when we > > reintroduce such problems. > > > > Another problem we found with the use of lambdas is that you have to be > > very careful because you can easily serialize things you don't need to > > serialize (even if they are serializable) > > > > > > On Tue, Apr 29, 2025 at 1:06 AM Tobias Gierke < > > tobias.gie...@code-sourcery.de> wrote: > > > > > Hi, > > > > > > Our company is a long time Wicket user on a large code base (10+ years, > > > >600k loc) and ever since lambdas got introduced in JDK 8, our Wicket > > > applications have occasionally been plagued by random crashes during > > > Wicket Page deserialization like this: > > > > > > |Caused by: java.lang.reflect.InvocationTargetException at > > > > > > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:109) > > > > > > at java.base/java.lang.reflect.Method.invoke(Method.java:580) at > > > > > > com.vodecc.voipmng.boundary.wicket.WicketApplication$5.lambda$get$0(WicketApplication.java:864) > > > > > > ... 63 more Caused by: java.lang.ClassCastException: cannot assign > > > instance of java.lang.invoke.SerializedLambda to field > > > <someClass>.<someFieldWithTypeIModel> of type > > > org.apache.wicket.model.IModel at > > > java.base/java.io > > > .ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2096) > > > > > > at > > > java.base/java.io > > > .ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2060) > > > > > > at > > > java.base/java.io > > .ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1349) > > > > > > at > > > java.base/java.io > > > .ObjectInputStream$FieldValues.defaultCheckFieldValues(ObjectInputStream.java:2697) > > > > > > at > > > java.base/java.io > > .ObjectInputStream.readSerialData(ObjectInputStream.java:2498) > > > > > > at > > > java.base/java.io > > .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2284) > > > > > > at > > > java.base/java.io > > .ObjectInputStream.readObject0(ObjectInputStream.java:1762) > > > > > > at > > > java.base/java.io > > .ObjectInputStream$FieldValues.<init>(ObjectInputStream.java:2618) > > > > > > at > > > java.base/java.io > > .ObjectInputStream.readSerialData(ObjectInputStream.java:2469) > > > > > > at > > > java.base/java.io > > .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2284) > > > > > > at > > > java.base/java.io > > .ObjectInputStream.readObject0(ObjectInputStream.java:1762) > > > > > > at > > > java.base/java.io > > .ObjectInputStream.readObject(ObjectInputStream.java:540) > > > > > > at > > > java.base/java.io > > .ObjectInputStream.readObject(ObjectInputStream.java:498) > > > > > > at java.base/java.util.ArrayList.readObject(ArrayList.java:981) at > > > > > > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > > > > > > at java.base/java.lang.reflect.Method.invoke(Method.java:580) | > > > > > > The offending member field in this particular crash has a type of > > > 'IModel<String>'. > > > > > > With "random crashes" I mean that the same code sometimes works and > > > sometimes crashes, seemingly dependent on the order in which > > > (capturing?) lambdas are created or called. > > > > > > I did spent some time looking into this and found quite a few > > > *unresolved* JDK bugs related to ClassCastExceptions during lambda > > > serialization: > > > > > > https://bugs.openjdk.org/browse/JDK-8154236 > > > https://bugs.openjdk.org/browse/JDK-8208752 > > > https://bugs.openjdk.org/browse/JDK-8275387 > > > https://bugs.openjdk.org/browse/JDK-8174864 > > > https://bugs.openjdk.org/browse/JDK-8174865 > > > > > > A comment on JDK-8275387 seemed especially enlightening: "The root > cause > > > is always the same: java.lang.invoke.SerializedLambda can not hold > > > enough information to correctly identify the which lambda should be > > > (de-)serialized". This all points to > > > https://bugs.openjdk.org/browse/JDK-8174864 as the root of the > problem. > > > That ticket mentions that currently, lambda serialization is a lossy > > > transformation since only the first invocation of any unique > > > "serialization key" will work (which would explain the randomness we > > > observed). > > > > > > We currently "fix" our crashes by using anonymous classes instead of > > > lambda expressions but obviously this is not ideal - especially since > > > (given enough indirections) it's quite hard to find out where the > lambda > > > causing the deserialization crash originated from. > > > > > > Cheers, > > > Tobias > > > > > > || > > > > > > > > > -- > > Regards - Ernesto Reinaldo Barreiro > > > -- Regards - Ernesto Reinaldo Barreiro
