Ok, it’s time for an update on “why does it take so long to fix this problem?”
As an appetizer: kryo vs collections.
When kryo serializes a map, it writes its class id followed by keys and values interleaved.
Upon deserialization, it instanciates the class and then call .put
for each entry
This fails when the map is immutable since .put
mutates (and is optional). That’s why we teach it to deal with IPersistentMap differently
the other asumption is that from the class alone it can recreate an empty collection.
Alas for some classes there’s no default constructor (not even a private one)
so objenesis performs a bare allocation were all fields are uninitialized
So this guy for example https://docs.oracle.com/javase/7/docs/api/java/security/Provider.html
is created as a bare object
but then .put
is called and what this object does is that it delegates to one of its field which is... uninitialized.
so I fixed this by “when no 0-arg ctor, uses field-by-field serialization”
</appetizer>
The current problem root are org.apache.http.config.Registry
instances defined by clj-http
which transitively refers many classes, especially in sun.security.*
which have to be serialized field by field but apparently they differ between AWS and my JDK
didn’t yet read your response, but thinking that we don’t have SLA for fixes, working in a way that doesn’t put too much stress 🙂
hum
aws lambda uses amazon linux ami
https://04d57u6034.execute-api.eu-west-1.amazonaws.com/repl/shell?args=cat%20/etc/issue
not the latest AMI apparently, at least on the box that the above lambda lives
meh, unable to run “java -version” subprocess, apparently
not going down this path
https://04d57u6034.execute-api.eu-west-1.amazonaws.com/repl/shell?args=yum%20list%20installed
🙂
yeah well, just remembered that was playing with the above lambda
maybe sane serialization can occur at a coarser level for all these security objects
hmm
would one have to write a Serializer for each class individually?
hum