[cdi-dev] [weld-dev] Overly restrictive serialization requirements

[Pete Muir]

Hi David,

On 24 May 2011, at 12:06, Pete Muir wrote:

> Moving this to the CDI EG list.
> 
> On 24 May 2011, at 05:18, David Blevins wrote:
> 
>> I find CDI 1.0 section 6.6.4 and some of the TCK tests a little confusing.  I know serialization like the back of my hand and much of that section does not line up with actual serialization requirements.
>> 
>> The bottom line is that you can't statically check a class's serialization capabilities.  Non-serializable object reference types are ok.  Fields of java.lang.Object and other non-serialzable types are ok.  The reference type does not need to be serializable, just the object at the other end of the reference needs to be serializable.  Obviously you can't check that at deploy time, you need the instance.

I think this is what you are missing, CDI can validate this at deployment time in many cases as it can resolve the actual bean (and hence concrete type) that will be injected. Of course, it can't actually check that the instance will serialize, but it can check some basic requirements (like it must impl serializable, and that it's dependency graph is passivatable). There are of course some special situations such as producers, when we don't know the concrete type at deployment type, and generally producers are passivation capable even if they don't implement serializable (we can only check this if the return type is final, then it must implement Serializable).

>>  You can't even check it at runtime as there are callbacks in the Serialization API that allow the instance to control it's own serialization.

This is a good point, the spec doesn't allow for custom serialization callbacks. I wonder if it makes sense that if the class does override serialization then CDI should assume the class is passivation capable.

>>  If the class implements Serializable you just have to trust it will be when the time comes.

Leaving aside EJBs (of which SFSBs are always passivation capable due to the guarantees of the EJB container), this is largely all the spec requires checking - that the entire graph of dependencies injected into a passivation capable bean is passivation capable.

>> 
>> Small example:  https://gist.github.com/988120
>> 
>> What's the point of mistrusting a class that claims to be serializable and adding CDI-specific restrictions on its fields, methods and constructor types?

Because we can do a much stricter check on the class as we know at deploy time exactly what it's fields, methods and constructors will be called with, this is something that Java cannot know so cannot enforce, with the proviso regarding custom serialization not being accounted for above.

>> 
>> 
>> -David
>> 
>> 
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev