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.
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
