JEP 8323072 and Serialization

[Alex Buckley]

Hi Shahan,

I thought we'd put the following in 8323072 but it turns out to be in 
https://openjdk.org/jeps/8305968#Embracing-integrity-by-default:

> Some classes already take responsibility for their serialization and
> deserialization by implementing the java.io.Serializable interface;
> libraries can take advantage by invoking writeObject and readObject
> on the classes via sun.reflect.ReflectionFactory, which is supported
> for this purpose. In the long term, we expect the Java Platform to
> offer better serialization.
Is sun.reflect.ReflectionFactory suitable for your objects?

Alex

On 3/27/2024 4:20 PM, Shahan Yang wrote:
> My apologies if this is the wrong place for this kind of question. I 
> maintain an Unsafe-heavy serialization library and I am weighing options 
> in light of Unsafe memory access deprecation.
> 
> It appears that the recommended replacement is to use VarHandles. This 
> seems reasonable at first glance, but it looks like VarHandles do not 
> support writes to final fields.
> 
> The problem is that there's a large codebase with a lot of application 
> logic objects to be serialized. The presence of final fields on those 
> objects aids in their readability. Currently, those fields can just be 
> set using Unsafe.put* methods during deserialization, but that isn't 
> possible with VarHandles. I don't think it's reasonable to ask 
> developers to make all of the application object fields non-final for 
> deserialization. It would also be an infeasibly large amount of toil to 
> add custom code to serialize and deserialize all those objects, relative 
> to what is possible with reflection.
> 
> I can think of a number of alternatives, but so far I haven't come up 
> with anything that avoids harming the readability of the code, 
> increasing toil, making serialization more error prone or slower (just 
> using regular Field reflection instead of Unsafe to set final fields?). 
> I'm less worried about records because the tight contract between their 
> constructors and their fields makes a code generation-based solution 
> quite clean.
> 
> Do you have any suggestions? Am I overlooking something that other 
> serialization libraries are doing here?
> 
> 
> Thanks,
> Shahan