This message was deleted.
# configuration-cache
s
This message was deleted.
c
It seems key to understand where
Caused by: java.io.InvalidObjectException: null array
is coming from.
I haven’t seen that specific error, though have wrestled with many CC / serialization issues. Is the remainder of the stack trace available beneath that?
r
unfortunately not. I put the full stacktrace at https://pastebin.com/WWaFhJQz
c
Thanks. Was able to track down perhaps this issue (the stack trace isn’t clear) in JDK ImmutableCollections, perhaps that ties into your custom object.
r
wow. thanks a ton. seems you're right. is that somewhere documented how immutableCollections are not doing well with CC?
c
Haven’t seen anything to that effect. It isn’t clear what the specific issue is - it looks like ImmutableCollections are Serializable - perhaps the Gradle CC serialization doesn’t like it. There is this tidbit in the docs:
Gradle uses its own optimized serialization mechanism and format to store the configuration cache entries. It automatically serializes the state of arbitrary object graphs. If your tasks hold references to objects with simple state or of supported types you don’t have anything to do to support the serialization.
As a fallback and to provide some aid in migrating existing tasks, some semantics of Java Serialization are supported. But it is not recommended relying on it, mostly for performance reasons.
And this link.
I’ve generally modelled any custom classes to be either Serializable and trivial, or a Gradle managed type (I dislike all that boilerplate code/overhead, but it does allow things to work with CC / Worker API etc where state is snapshotted).
…and sometimes with a
.toSaneObject()
adapter, such that the Gradle managed type is limited to shuttling the data between execution scopes, once on the otherside we have a cleaner object to work with.
r
yeah I did similar things
a
Good catch. It seems we don't have a codec for Java11 collections, created via
List.of()
,
Set.of()
,
Map.of()
. Since these are part of Java standard library I think we should add them and not fallback to Java Serialization. I opened https://github.com/gradle/gradle/issues/26942, but I am not working on cc, so cc team will triage it