I haven’t read the ticket carefully enough, but I’m wondering if you know: is the problem completely deterministic? If so, the tests should always catch it if there is a test that tests the serialization of each lambda (which is a lot of work for something that should just work in the first place!).
Jon > On May 1, 2025, at 8:38 AM, Ernesto Reinaldo Barreiro <reier...@gmail.com> > wrote: > > Hi, > > On Thu, May 1, 2025 at 9:22 AM Emond Papegaaij <emond.papega...@gmail.com > <mailto: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
